On Mon, Feb 12, 2024 at 12:57 AM Matthias Koeppe <matthiaskoe...@gmail.com> wrote: > > On Sunday, February 11, 2024 at 3:34:46 PM UTC-8 Dima Pasechnik wrote: > > On 11 February 2024 22:47:24 GMT, Matthias Koeppe <matthia...@gmail.com> > wrote: > >On Sunday, February 11, 2024 at 1:46:40 PM UTC-8 Matthias Koeppe wrote: > > > >I'll make an attempt to quantify this cost > > > >Here's an illustration of the workflow for making python_build a standard > >"wheel" package, as proposed in > >https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc: > > What you outlined is the initial one-time cost. > > > That's correct, that's what I did in that post. > > > There is also a cost of maintenance, which eventually gets bigger than the > initial cost: the thing gets outdated, its dependencies get outdated, this > all requires updates, tests, conflict resolutions ---something that you get > largely for free if you let go of the package dependency micromanagement, > relying instead on the Python universe out there to do the job. > > > That's where a possible sleight of hand happens. > Let's please do this discussion at normal speed, giving the audience a chance > to observe the facts and form their opinion. > > Pinning packages to a set of tested working versions is a standard practice, > and as a matter of fact part of best practices to achieve stability in > various deployment situations, reproducibility, etc. > > In the Python world, such pinning is done using requirements.txt, > Pipfile.lock, and environment.yml files. > In the Sage distribution, we pin using package-version.txt and tiny > requirements.txt files.
as well as install-requires.txt and spkg-configure.m4 - they also in some cases pin versions, strictly,or not. Now you can lament about the lack of more developers joining the project... (they come, they see the insanity of controlling versions in 5 different somewhat incompatible ways, they leave). > > When updating the pins, testing is always necessary; it does not come for > free. Yes, we have our automatic tests, but in two of the examples that you > mentioned, Sphinx and Jupyter, some manual inspection is necessary. Now, at last, tell us what makes Sage so special that we must vendor sphinx and jupyter (and pytest (proposed), and tox, and...), unlike, say, sympy, or scipy? I imagine they spend developers' time on something more productive than repeating the work done elsewhere, no? > > A question to ask is what tooling is available to update the version pins, > and what the cost of using the tools is. For a typical upgrade, by improving > our tooling, we have reduced the work to just typing "./sage -package > update-latest sphinx --commit". In the Sphinx upgrade, > https://github.com/sagemath/sage/pull/37129/files (needs review), I ended up > updating 25 packages, so I had to use a command like this 25 times. It's > repetitive, maybe it takes 20 minutes total, but it's not remotely something > that I would use the phrase "Sage has shot itself in the foot" for. The whole thing of a zillion vendored packages makes Sage uniquely hard to package, and use outside of its own venv. These 25 packages just don't need our version micromanagement, it's already done outside of the project. Can we please start to let go of this "vendor everything" mentality? Please? > > (Our tooling for "pip" packages is actually worse than that; "./sage -package > update-latest" does not support them, an easy to implement wishlist item. > Being able to run "sage -pip install -U sphinx", then test, then updating the > pinned versions according to "./sage -pip freeze" -- also that's an easy to > implement wishlist item.) > > -- > 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/7f062b45-a5b3-49de-83e1-4f2f47eb96c2n%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/CAAWYfq3AufJ0470DA1WYkCZd5eAcW7nwMC6eUhtLpjoMy91TDQ%40mail.gmail.com.
