On 20 February 2024 01:57:40 GMT, 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 number of dependencies has grown to the point it has gotten too hard to
maintain, especially if one aims to support as many Python versions as we do.
These dependencies force one to have fragile, and temporary, version-dependent
workarounds in the configuration.
We don't have full-time (or even part-time) software engineers who can be
tasked with such tedious stuff. Meanwhile maths bug pile up, but one has to do
this ever growing maintenance...
That's why it's better to let go of as many explicit dependencies as possible
now.
> 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/F329CEC3-622C-4F93-A676-5369F6C7B135%40gmail.com.
