On Sunday, September 26, 2021 at 1:53:38 PM UTC-7 Nils Bruin wrote: > On Sunday, 26 September 2021 at 13:32:28 UTC-7 Matthias Koeppe wrote: > >> >> This does not describe our current practice or policy. All public names >> in all Python modules are part of the API; when we move anything around, we >> use deprecation via lazy_import etc. >> >> I think deprecation only gets used for things exposed in the "sage global > namespace", i.e., sage.all. That certainly used to be the case. Other > changes are/used to be fair game. >
No, that hasn't been true in a long time. We need to keep sage.all in some form, because it's pretty essential that > people can "write sage" (minus preprocessor) by doing a "from sage.all > import *". I don't think we'll get an alternative for that [I agree that > libraries should not be doing that], because there needs to be an option > for people to get their code working without having to track down a dozen > import statements. > Yes, interactive use is a separate issue. Right now I am only concerned about library use. > Recent example of "rough" deprecation: from 9.2 to 9.3: complex_number.pxd > just disappeared. > Well, we seem to have no deprecation mechanism for Cython headers. > I think these are the kind of things that will limit the modularization > of sagelib: it's just too integrated. It's certainly going to be a > constellation of packages that have *exact* versions as prerequisites. > Version ranges will not be an option. > Yes, the modularization plan of https://trac.sagemath.org/ticket/29705 will keep a monorepo, and I have no plans to introduce fine-grained version range dependencies between different parts. Through the top-level ./bootstrap script, all versions are kept in sync. > At that point I don't quite see what the benefit is to split it up in > separate packages rather than just have one big package. > The big package has gigabytes of compiled dependencies, which limits the use of parts of the Sage library in other Python projects. Modularized parts with much lighter dependencies have a chance of getting used (and attract developers) outside of the traditional Sage user community. -- 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/cd2ed7f9-e5de-4b6c-bd6c-2cb05e5c52c8n%40googlegroups.com.
