On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe <matthiaskoe...@gmail.com> wrote: > > On Wednesday, April 26, 2023 at 12:33:13 PM UTC-7 William Stein wrote: > > On Wed, Apr 26, 2023 at 12:27 PM David Roe <roed...@gmail.com> wrote: > > I do think it would be valuable for other people on this list to offer some > > thoughts on whether Sage should prioritize reducing the number of > > foundational packages we offer in the short term (as Dima is advocating) or > > keeping them to help maintain support (as Matthias is advocating). > > Regarding your question David, I really like the way it is phrased, > since whether or not to support > packages is a function of the resources we have, which really is a > function of the community > and their availability to work on things. [...] > > > Actually the question happens to mischaracterize my position. I'm in favor of > removing unmaintained packages from our distribution when there are *real* > problems. For example, I pushed for removing the R package because it was > long outdated and nobody was stepping up to take care of it and much better > ways to install it than we offered. But the python3 package (and the > gcc/gfortran package, which Dima brought up again in > https://groups.google.com/g/sage-devel/c/LWKdRM2Gn-s/m/GAuPgzCACwAJ above) > have concrete purposes of platform support and ease of install.
gcc (a package that provides C/C++ compilers, not to be mistaken with gfortran) has absolutely no use in 2023 (apart from some people now and then trying and failing to build it on a system with a bad toolchain, and wasting out time asking for help to build these) dutto python3 package. ditto the whole Jupyter ecosystems, with their ever growing number of dependencies. > And these packages do not have a *real* maintenance problem. (I have > maintained them since 2020.) So demanding that we need to drop these packages > is attempting to manage my time, which is not necessary. well, we can barely keep up with security updates for e.g. openssl. It took Thierry to provide a patch today, and me converting it into a PR, else we probably would be still shipping openssl version with severe CVEs. And this shows that we do have a real maintainance problem: the fact that you, Matthias, (try to) maintain these unneeded packages takes toll on other developers, cause it's a never ending task to carry the dependency buggage, review corresponding PRs, etc. Sage is not a single person project, and so it's not only your time, Matthias, it's other people's time you take away from them, because you want to carry this unneeded baggage forward. Instead of e.g. updating openssl we could have done something more meaningful today. > > Moreover, the question poses a false dichotomy; there is a third option. > Quoting my key message from that very sage-devel thread from 2 years ago > (https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/GLMxIirPAwAJ (link to > message)): > > If we say that availability of gfortran in any of these user-installable > > distributions is the solution, then this applies to lots of other spkgs as > > well --- perhaps to ALL of our non-Python packages. > > So essentially it is to say, let's stop maintaining the Sage distribution. > > > > This certainly *could* make sense for the project -- but a lot of work is > > needed to bring missing packages to these distributions: conda-forge does > > not have all of our optional packages, homebrew is missing a lot of > > packages. On the Sage side, also working on the tasks > > https://trac.sagemath.org/ticket/30914 (creating proper upstreams for some > > Sage-specific packages) will help. > > > > The big problem is that the middle ground between "Complete Sage > > distribution that works in most use cases" and "No Sage distribution" is > > worse than both of the extremes. By removing spkgs one by one, we would > > make the Sage distribution less useful. So this is not a meaningful process. I don't think this is true. Noone will even notice removal of gcc the spkg, or python3. It will become more useful, as it will have less obsolete parts, which nobody uses, but which demand constant attention and resourses, as more time could be put into important parts. > > My 2023 summary of the situation: > > 1. I would be in favor of abandoning the Sage distribution (despite the fact > that I have certainly put a lot of time and energy into it) **if** it is > determined that the user community is sufficiently served by conda-forge > packaging. > But I think that this would require for more developers to engage with the > conda-related issues (example: https://github.com/sagemath/sage/issues/35528). This can be done if we drop the ballast, not any other way. > > 2. I'm not in favor of chipping away 1 package at a time in the name of > unsubstantiated, vague notions that a package is "ballast slowing down Sage's > progress". It's not vague, it's very concrete. It has been done in the past, cf e.g. R/rpy2, tar, etc., it can be continued just fine. > > > -- > 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/ffb0b1f4-a143-46df-b65f-b9ac3ad3e70dn%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/CAAWYfq075EmmZz6h_s4ppA-c2X9C9KHGQN3T%2BuPevOJ4Nq7BOA%40mail.gmail.com.
