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. Now for a smaller package without (many?) dependencies, one can probably get away with pinning just down to the major release, but the benefit of doing that is pretty marginal. So I am against allowing standard packages to be "pip" packages --- the "wheel" approach seems like the right tradeoff here as (a) the final package is sourced straight off PyPI so we don't have to build it (b) the result is completely stable. Best, Nathan [1] https://snappy.computop.org -- 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/5b0a8e66-3b2c-48df-8287-258d8252decdn%40googlegroups.com.
