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. 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/c01e6162-99b2-44f0-9173-10ee199bd536n%40googlegroups.com.
