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. 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. 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. (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.
