On Thu, Jun 22, 2023 at 1:44 PM Matthias Koeppe <matthiaskoe...@gmail.com> wrote: > > On Thursday, June 22, 2023 at 12:49:29 PM UTC-7 Francesco Biscani wrote: > > On Fri, 9 Jun 2023 at 02:02, Matthias Koeppe <matthia...@gmail.com> wrote: > > building binary wheels to be distributed on PyPI (in addition to the source distributions) will be one of the key steps in order to make it very user-friendly -- i.e., on par with doing "pip install scipy" on standard platforms. > > It is normal practice of Python projects to create binary wheels and make them available on PyPI. There is sufficient mainstream infrastructure (such as https://github.com/pypa/cibuildwheel) that makes it easy. > > > What is your plan for dealing with sage's non-Python dependencies? > > Binary wheels which bundle compiled non-Python dependencies using tools such as auditwheel are extremely fragile, as there is nothing preventing the user from installing a package which might bundle a different version of the same library, resulting in hard-to-debug erratic runtime errors due to ABI inconsistencies, symbol collisions, etc. > > > That's of course a valid concern and a well known weakness of Python packaging. In general, there is no mechanism to prevent users from shooting themselves in the foot. We can, however: > (1) keep the non-Python library dependencies of each of our distribution packages minimal (that's one of the reasons why the plan includes distribution packages that are keyed to a single library or set of libraries, like sagemath-flint); > (2) test to ensure consistency with the published binary wheels of upstream packages (for example, gmpy2 for the gmp, mpfr, mpc libraries); > (3) work with upstream projects so that they have a consistent process for building wheel packages; > (4) avoid/remove sage-specific library glue when there are already dominant packages in the Python ecosystem that do this job (for example, https://github.com/sagemath/sage/pull/35368 replaces a custom Cython interface to the cbc library by the upstream cylp library).
(5) provide a WebAssembly option WebAssembly is typically about half the speed as native code (at best), but it is highly cross platform and self contained. WebAssembly is difficult mainly when you have to deal with the OS somehow (e.g., filesystem, networking, etc.), and fortunately, a lot of the code in Sage is math libraries that support a non-threaded mode, so are particularly easy to port to WebAssembly. A good example is Pari, which is one of "sage's non-Python dependencies". The word "Web" in the name WebAssembly doesn't imply that it is only for use in a web browser. It's used widely outside of browsers. One could compile something like pari to webassembly, then make use of a popular Python library like https://github.com/wasmerio/wasmer-python. This wasmer-python itself is an extension module to Python (written in Rust), and the platforms it supports are listed here: https://github.com/wasmerio/wasmer-python#supported-platforms Incidentally, building Pari to WebAssembly is officially supported and regularly tested by Bill Allombert. Here's his demo: https://pari.math.u-bordeaux.fr/gpexpwasm.html -- William > > -- > You received this message because you are subscribed to the Google Groups "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/dab4c686-8791-4280-903c-5a982181a352n%40googlegroups.com . -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GBOrrg-yY-fVXfFE2X2SCKsEmD2h35z3-y-Giu4S5_yww%40mail.gmail.com.
