On Tue, Feb 20, 2024 at 1:57 AM Nathan Dunfield <nat...@dunfield.info> wrote:
> On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote, > responding to Dima: > > You said: "The difference between wheel packages vs pip packages is that > the latter don't require pre-fetched wheels, and absence of the need for > package (micro)management." The implication is that changing the package > management system is, maybe not part of this proposal, but a next step. In > other words, I'm getting this impression from your words, not by other > "certain parties." > > You said: "My proposal is in fact aimed at reducing the number of pinned > Sage dependecies, drastically." (You have made similar comments elsewhere > in this thread.) How does (1) accomplish this? Either I'm missing something > or you have not spelled everything out in your proposal. > > You said '"Allow" does not mean "Make all of the", it should be obvious.' > > "Allow" does not cause any changes to happen drastically. So what exactly > are you proposing to accomplish these drastic changes? If you have a > roadmap in mind, it would be helpful if you described it. > > > My understanding is that allowing standard packages to be pip packages > could greatly reduce the number of pinned Sage dependencies for two reasons: > > 1) a build-from-source or wheel package must explicitly pin its version, > but, more importantly, > > 2) a pip package is allowed to install additional dependencies of PyPI > that are not recorded anywhere in the Sage repo. > > A simple example is pytest. Here it is as an optional pip package: > > https://github.com/sagemath/sage/tree/develop/build/pkgs/pytest > > To be upgraded to a standard package, under the current policy would need > to be turned into a "wheel package" requires adding its dependencies like > so: > > https://github.com/sagemath/sage/pull/37301 > > Here, pytest has just a few dependencies, but jupyterlab has more like 50 > when you include dependencies of dependencies. > > -------- > > Personally, I think the current system of having everything pinned and > explicitly recorded is the right choice, being more stable in my experience > with other projects. > the experience of Sage macOS app is that it's better to leave Sage's jupyterlab (with its ~193 packages) totally aside, and use the undiluted upstream jupyterlab instead, see https://github.com/sagemath/sage/issues/37533#issuecomment-1981375822 > In any event, switching to a pip package for e.g. jupterlab doesn't affect > the final size or complexity of Sage as installed, just how many moving > pieces there appear to be if you look in "sage/build/pkgs". > > Best, > > Nathan > > -- > 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/f81b8284-cb48-44fe-a3f7-158be2438335n%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/f81b8284-cb48-44fe-a3f7-158be2438335n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAAWYfq2mMSU%3DjcjL%3DqJc69%3DGQ2pNDZt4FDVaJ%3Db%2Bb3N8gj72ww%40mail.gmail.com.
