People interested in maintaining sagelib should only care about the version constraint in the pyproject.toml file (e.g. if they decide that a new feature of numpy is needed, then the version constraint of numpy should be changed accordingly). People interested in maintaining sage-the-distro should maintain sage-the-distro. If they (for some reason) need a tighter version constraint than sagelib, then it of course falls in their responsibility to maintain this constraint. This is similar to other distributions that are maintaining a consistent set of package versions (e.g. the conda lock files in the main repo, or linux distros). But obviously these are activities downstream of sage-the-library.
> Simply recovering the files build/pkgs/*/version_constraints.txt will do it? Yes, that should work with some trivial changes in the bootstrap script (where currently the corresponding version constraint file is generated). On Thursday, August 22, 2024 at 12:35:57 AM UTC+2 Nils Bruin wrote: On Wednesday 21 August 2024 at 15:29:05 UTC-7 Matthias Koeppe wrote: On Wednesday, August 21, 2024 at 2:12:30 PM UTC-7 tobia...@gmx.de wrote: > the version constraints of the packages that happen to be build dependencies of the Sage library (enumerated in https://github.com/sagemath/sage/blob/develop/bootstrap#L36) are set in https://github.com/sagemath/sage/blob/develop/src/pyproject.toml#L3 Right (adhering to the standard of modern python libs) > The tighter version constraints are needed by the Sage distribution Then please specify these version constraints in sage distribution and not in sage-lib (eg by providing a version_constraint.txt file that is compatible with the version constraints of sage-lib and the tighter constraints set by other packages). No, I will not start maintaining two sets of constraints. I don't think *you* would need to maintain that set. It would just be something to maintained. If Tobias argues convincingly that there is benefit to maintaining a different set of constraints, he'll probably be able to find people (himself maybe?) who are willing to maintain such constraints. If at all possible, no maintenance task should fall to any single person. -- 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/4223ad95-cace-4348-95c1-a9bf446cfb1en%40googlegroups.com.