One way or another, no faithful packaging of Sage the distro exists, besides Sage the distro itself. The reason is that it's too big, too verbose with it's 400 packages, most of which are just unpatched PyPI packages, pinned to relatively random versions, providing Python, Jupyter and Sphinx, and common libraries and tools like zip and patch.
Successful packing of Sage (by Gentoo, by Void, by Arch, by Conda) is packaging sagelib, and relying on the rest of the environment to provide what can be provided with a reasonable effort. Today I received a message from a Sage contributor urging to consider forking sagelib, even mentioning possible funding for such an effort, with the primary goal to make it easy to package by Linux et al. distros. I think a similar goal can be accomplished with less effort, e.g. by splitting the main Sage repo into sagelib and sage the distro. I hope there is still a room for consensus, before a "hostile" fork happens. And to pre-empt the question "but who will work on sage the distro", I can answer now: these who want to work on it. Don't force people who don't need it into working on it, just cause we have a monorepo, and only release it as a whole, and there won't be conflicts. E.g. you want to package in Sage the distro Python packages which use Rust (it's getting more and more popular) - fine, you can have fun doing it, but I wouldn't participate in it. E.g. you want to figure out the minimum numbers of packages you need from an old OS in order to build all of Sage - fine, but it should not slow down sagelib development, and should not be a consideration on how sagelib is developed (so e.g. dropping old Python versions should happen faster, it should not be dictated by the fact that a CI for this old OS and old python is already there). On 12 January 2024 21:00:15 GMT, Nils Bruin <nbr...@sfu.ca> wrote: >On Wednesday 10 January 2024 at 16:59:22 UTC-5 Dima Pasechnik wrote: > >When it was discussed whether we wanted to use it, the main objection was >that it needs root (once, explicitly, to set up, then implicitly), thus >unsafe. >Conda was mentioned as a better option. But Conda is much bigger. > > >Conda is also multi-platform. A packaging of sagemath through conda is (or >at least should be) usable on both linux and OSX. Doesn't that make it a >more attractive target than homebrew? > >Also, why not package sage in multiple ways if there's a taste for it? Like >the packaging in linux distributions¸ it doesn't all need to be done by the >core sage team, but probably at least one or a few should be, to guarantee >that there's actually a way to get sage working for many people. As long as >someone volunteers to maintain a packaging method, what's the downside of >having it? > >If there are people to maintain both homebrew and conda, can't we just do >both? > >-- >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/adb84226-f0ca-4007-be6f-705ac0f59a9cn%40googlegroups.com. -- 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/44FC00CD-154C-43B5-AA83-04435D897B98%40gmail.com.
