On Mon, Feb 12, 2024 at 6:02 PM Matthias Koeppe <matthiaskoe...@gmail.com> wrote: > > On Monday, February 12, 2024 at 3:18:05 AM UTC-8 Dima Pasechnik wrote: > > > 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. > > > These files serve a different purpose. They declare acceptable version ranges.
requirements.txt might as well specify the range, and this is used too e.g. build/pkgs/phitigra/requirements.txt has phitigra>=0.2.6 So this is all blurred and confusing > In pure Python packages, this exists as well, as you know. > It is done in pyproject.toml "dependencies" (previously setup.cfg/py "install-requires"). > > Talking about these here is a distraction that does not serve the discussion of this topic. > > Now, at last, tell us what makes Sage so special that we must vendor > sphinx and jupyter [...] > > > Note that I have not expressed much of an opinion yet on your proposal. > We'll get there. > > But as I have pointed out several times previously, you are using the word "vendoring" in a polemic and idiosyncratic way, which does not serve the discussion. More below. > > > 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 [...] > > > 1. Sage does not "vendor". What is in build/pkgs is _metadata_. It's just text. Sage _pins_ versions of packages, so there is information on the version. of course, I never said that metadata is vendoring, it's certainly not, and this is a deviation from the topic. > > 2. Also the large Sage source tarball does not "vendor". It is a shipment of a distribution. Distributions don't "vendor". It's the job of a distribution to ship its components. This is not correct. Sage is not a distribution, and I am using the verb as described here: https://en.wiktionary.org/wiki/vendor#Verb *vendor* (third-person singular simple present *vendors*, present participle *vendoring*, simple past and past participle *vendored*) 1. (transitive <https://en.wiktionary.org/wiki/Appendix:Glossary#transitive>, software engineering <https://en.wiktionary.org/wiki/software_engineering>) To bundle third-party <https://en.wiktionary.org/wiki/third-party> dependencies <https://en.wiktionary.org/wiki/dependencies> with the source code <https://en.wiktionary.org/wiki/source_code> for one's own program. * I distributed my application with a vendored copy of Perl so that it wouldn't use the system copies of Perl where it is installed.* 1. (transitive <https://en.wiktionary.org/wiki/Appendix:Glossary#transitive>, software engineering <https://en.wiktionary.org/wiki/software_engineering>) As the software vendor, to bundle one's own, possibly modified version of dependencies <https://en.wiktionary.org/wiki/dependencies> with a standard program. *Strawberry Perl contains vendored copies of some CPAN modules, designed to allow them to run on Windows.* According to this definition, everything in upstream/ is vendored (except our own packages, like configure.) > > -- > 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/e2fd4a63-c029-4c1a-92eb-4a81c3ac6a16n%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/CAAWYfq1U%3DjrpU3Yn4K%2BX9kpm7p%3DENgLqch2z%2BH3ABPaK8fBU6g%40mail.gmail.com.
