On 17 February 2024 17:16:07 GMT, Matthias Koeppe <matthiaskoe...@gmail.com>
wrote:
>On Saturday, February 17, 2024 at 7:06:27 AM UTC-8 Nathan Dunfield wrote:
>
>On Friday, February 16, 2024 at 11:17:37 PM UTC-6 Matthias Koeppe wrote:
>
>If one does not care about the use case without internet access, then it's
>just the following:
>- Pinning, as you mentioned (see also
>https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ above,
>where I discussed some details of this, including risks of leaving packages
>unpinned)
>- Dependencies: "pip" packages can pull some of their build-time and
>run-time dependencies directly from PyPI, without us mirroring these
>dependencies in SageMath metadata. That's a mild convenience for
>developers, of importance if one wants to leave the version range wide
>open; but also has risks of instability.
>
>
>Matthias, thanks for the clarification. I think pinning the version of a
>"standard" package, including all its dependencies and down to the minor
>release, is likely the best approach. Based on my experience with snappy
>[1], not pinning things will result in CI runs failing "out of the blue"
>because one of the dependencies got updated. With a small project like
>snappy, this is pretty occasional and serves as a way to flag issues with
>new upstream releases, but with Sage my guess is that such failures would
>be frequent. Suppose that each time the CI runs on a new PR, there's a
>10% chance of it failing because some completely unrelated dependency
>shifted; that would be a major annoyance to seasoned Sage developers and
>very discouraging to newcomers.
>
>
>Thanks a lot, Nathan, for this point.
>I share the same concern based on the amplification of the failure
>probability, due to the large number of dependencies in Sage.
My proposal is in fact aimed at reducing the number of pinned Sage dependecies,
drastically.
Because most of them are either dependencies of Jupyterlab, or of Sphinx, or of
Python build system, and none of the them should be Sage's concern to package,
with all their dependencies.
If you itch to pack the said dependencies, please do it in a separate repo/PyPI
package, which can be consumed by sagelib to get the desired pinned
dependencies (and test all this in the existing CI, why not?)
But stop tying them up with sagelib - which in effect forces people interested
in sagelib to slave away on packaging 300 dependencies, most of which aren't
even tested by CI in any way, besides building.
Please liberate sagelib from the cabal of the ftontend, etc.
Sagemath is not a disto - no sane distro puts everything in one flat directory
structure.
Sagemath is an insane pile of needlessly vendored packages.
>
>I'll note that recently we have merged PR
>https://github.com/sagemath/sage/pull/35986 by Tobias Diez, which
>implements full version pinning for our conda-forge installation methods.
>See
>https://github.com/sagemath/sage/blob/develop/src/environment-dev-3.11-macos-arm64.yml#L329
>
>-- pytest is fully pinned down to the build hash. This change was motivated
>specifically by the fast changes of conda-forge (as a rolling
>distribution), which was one major cause for the instability of the CI
>Conda workflow.
>The tooling for this is https://conda.github.io/conda-lock/ and Tobias's
>script
>https://github.com/sagemath/sage/blob/develop/.github/workflows/conda-lock-update.py
>
>The proposed policy change to allow standard packages to be "pip" packages
>would run in the opposite direction.
>
--
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/F661E14B-700E-4DCF-959A-DED3EFFB5898%40gmail.com.
