On Tuesday, October 8, 2024 at 1:23:55 PM UTC-6 Nils Bruin wrote: - the examples we have of bits of software developed as part of sage that ended up as library components of other projects are peripheral, interfacing parts that were spun off into independent libraries.
- we don't have examples of core functionality of sage getting adopted as a component of another project The most obvious reason for this is that it too hard for a project to adopt core functionality of Sagewith the current organization of Sage. Making that easier was one of the main motivations for the modularization project. So this is circular reasoning. Against that background: Do you mean against the background based on circular reasoning? what purpose would modularizing the core of sage serve and what benefit do we think to derive from it? Making it practical, or at least possible, for core functionality of sage to be reused. That has always been the purpose. Once distributions are happy packaging sage in a conventional way, perhaps people could easily generate flatpaks or snap packages as well, which should be more stable (they'll be huge, though). The Sage_macOS binary package is a (compressed) 1GB download which expands to about 3.5GB. A 1GB download is not huge these days. The size of the raw Sage github repository is about 620MB. After building Sage it swells to about 10GB. A snap or app-image would use squashfs, which is compressed, even after installation. So it shouldn't be larger than, say, 2GB. (Flatpaks are not compressed after installation.) Pypi packages have a default size limit of 100MB per file and 10GB per project. - Marc -- 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/6e9152f2-f134-447c-bf2d-20b853eb67e7n%40googlegroups.com.
