On 27 February 2024 18:50:55 GMT, John H Palmieri <jhpalmier...@gmail.com>
wrote:
>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.
At the moment we are talking about using this option,
have pytest* and build, as standard pip packages, whereas they are now optional
pip packages.
This is all by now. We lived for years with them as optional packages, nobody
had problems with them, why would they all of a sudden started causing problems?
>
>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.
No known to me project vendors pytest on the basis that doing otherwise would
"lead to instability".
Let us be practical - there is no reason whatsoever to vendor pytest*.
Therefore standard pip packages should be allowed.
No known to me project vendors jupyterlab, either.
This is just FUD that a well maintained package like
pytest must be vendored.
It's as believable as saying that tar must be vendored, cause a version not
tested might lead to maths errors.
> 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.
We can still pin version requirements on pip packages. And indeed for maths
packages,
a handful of these which are maths, we can always do this, why not?
> 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.
Sure, I am fine with this. All what my proposal meant to do is to be able to
get rid of lots of vendored packages which have nothing to do with maths, they
are just guts of pytest, Jupyter, other common place packages.
>
>
>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/D1E85726-8CD8-47D9-9DD4-1168B97CBF21%40gmail.com.
