Regarding the proposal to allow standard packages to be pip packages, no one really knows how much people rely on the all-in-one tarball that we currently distribute. No one really knows how often the "make download" option is used for people who just clone the git repo and want to do all of their downloads at once. Since we don't know, the absolute safest course of action is to not change anything, but maybe that's too conservative. A pretty safe second choice would be to have "make download" also download the relevant files for pip installation and tell pip where to find them. If we implemented this second choice, I would support this aspect of Dima's proposal.
My impression from Dima's posts is that he would like us to frequently not provide version information for pip packages. Here are some of my thoughts: As Nathan points out, this will likely lead to instability. Someone will upgrade some component, and most of the time that will be fine, but occasionally it will break something on some platform, and it could be annoying to track down the cause. If this leads to Sage failing to build, that's not great, but it would be *far worse* if Sage built and ran but produced some mathematically incorrect answers. Being able to control all of the versions means that our doctests are pretty robust. If we really want to go down the road of unpinning version requirements, I propose that we *always* pin version requirements for the mathematical components of Sage. If Jupyter or Sphinx doesn't work right, it doesn't affect the mathematics, but if linbox or pari don't work right (or ore_algebra, if you want a pip package), people could be getting different answers on different platforms and we might not know about it for a while. To maintain the mathematical integrity of the project, we should keep very careful control of the mathematical components of Sage. On Saturday, February 24, 2024 at 3:40:02 PM UTC-8 Matthias Koeppe wrote: > On Monday, February 12, 2024 at 6:42:07 PM UTC-8 Matthias Koeppe wrote: > > On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote: > > > *Proposed action items: * > *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so > that "git clone" is described as the primary way to obtain the Sage > sources. That the big release tarball is available can be a footnote in the > Installation Guide ( > https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps) > > for the limited no-internet connectivity use case. > > > That's now https://github.com/sagemath/sage/pull/37309 (needs review) > > > Thanks for all comments on the PR. Ready for final review. > > > *B. *Likewise, get rid of all of these "Download Sage source code" pages > (https://www.sagemath.org/download-source.html, > https://www.sagemath.org/download-latest.html), mirror selection, etc. > from the Sage website. > > That's now https://github.com/sagemath/website/pull/466 > > > This one has already been merged, thanks, Harald! > The "Download" menu no longer sends people to the tarball download pages. > The pages are, of course, still there, and links from the installation > guide point to them. > > [image: Screenshot 2024-02-24 at 3.34.47 PM.png] > > On Tuesday, February 20, 2024 at 6:44:32 PM UTC-8 Matthias Koeppe wrote: > > On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote: > > Prompted by the discussion of space use on the *local machines* of users > and developers, I propose another item in addition to A and B: > > *C. Advertise use of "git worktree" and recommend symlinking the > "upstream" directory.* For testing a new release when you have an > existing clone of the repository, using "git clone" another time is > overkill as it creates another copy of the .git directory. And there is no > point in having multiple copies of the "upstream" directory, as the > filenames of the tarballs change whenever the contents change. > > > That's now https://github.com/sagemath/sage/pull/37411 (needs review) > > > This one has been positively reviewed. Thanks, Lorenz! > > -- 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/b448c1da-eb22-4402-aea7-09bec2ab88e9n%40googlegroups.com.
