On Wed, Apr 24, 2024 at 9:29 PM Nathan Dunfield <nat...@dunfield.info> wrote: > > On Wednesday, April 24, 2024 at 2:26:37 PM UTC-5 Oscar Benjamin wrote: > > Thanks Marc. This seems like a good example of a useful part of Sage > that can be extracted to something much smaller than Sage. > > Presumably though a hypothetical person who wants CyPari2 but not all > of Sage can already just use CyPari so that person is already well > served. > > > Correct. > > > Is the plan that CyPari2 would effectively replace CyPari? Then the benefit > is not needing to maintain CyPari separately from > sagelib's CyPari2 dependency? > > > No, rather CyPari is an example of the sort of free-standing Python package > that could be extracted from Sage. Modularization would create more of > these, in varying sizes and levels of granularity. > > Some level of modularization is necessary to address what William Stein > described last year as: > > The fundamental and massive problem that I think SageMath has is that it is > not part of the Python ecosystem, > by which I mean that there is no good way to do "pip install sagemath-[foo]", > in sufficient generality. > > PROBLEM: SageMath is not part of the Python ecosystem. > > DEFINITION: A piece of software is part of the Python ecosystem, if you can > do "pip install <software-name>" on > basically the same platforms as the intersection of where you can install > scipy/numpy/matplotlib/pandas, > and with somewhat comparable resource usage (i.e., installing Sagemath can't > use 100x of the time/space of > the above, as that would be unfair). > > On a related note, the reason that CyPari2 and CyPari are still separate > relates to what Marc mentioned earlier about tension between two models of > installing software: the "Linux distro way" using a system-level package > manager (where there is typically only one version of any given library on > the system) and the "Python pip" way (where all needed libraries are > statically linked into the wheel). CyPari2 follows the first, CyPari the > second. (This story is further complicated by the fact that, from a user's > perspective, conda is like "Python pip" in that it is orthogonal to any > system libraries, but developing packages for conda is akin to building them > for a Linux distro.)
There isn't a big problem to set up a GitHub wheel builder for CyPari2, so there is not really a sea of difference here in this sense. Also, probably it should be mentioned that linux distro way/pip way can be very nicely combined using a python venv. So one can use system packages, but add up more packages, and, if needed, override system packages with other versions. > > Of course, most projects in the scientific Python community support both > models, but there is technical overhead in doing so, which I believe is the > root of some of the current conflict. > > Best, > > Nathan > > -- > 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/60a60056-f8e9-417e-b03a-1dcfcbc3c6ebn%40googlegroups.com. -- 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/CAAWYfq0oqXa1J4pJM78Mk8pb0YCyKMQfmFyp-NdpXQS6Yy_dRA%40mail.gmail.com.
