Re: [sage-devel] Re: Refactoring tasks in the Sage library to support modularization

On Sunday, September 26, 2021 at 9:28:18 PM UTC-7 wst...@gmail.com wrote: > With use of __init__.py the above would be "from sage.PAC.KAGE import > ...". > Side remark: Native namespace packages (PEP 420) do not have __init__.py; and this is the technical mechanism that the modularization plan

Re: [sage-devel] Re: Refactoring tasks in the Sage library to support modularization

On Sunday, September 26, 2021 at 9:28:18 PM UTC-7 wst...@gmail.com wrote: > The modularization of the Sage library could have lofty longterm > goals, but start with one single package that is included > in Sage, but is also a separate Python package and is even published > to pypi and other

Re: [sage-devel] Re: Refactoring tasks in the Sage library to support modularization

On Sunday, September 26, 2021 at 9:28:18 PM UTC-7 wst...@gmail.com wrote: > On Sun, Sep 26, 2021 at 1:10 PM Nils Bruin wrote: > > On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote: > > > >> 3. Break up Cython modules that depend on several C/C++ libraries > simultaneously

Re: [sage-devel] Re: Refactoring tasks in the Sage library to support modularization

On Sun, Sep 26, 2021 at 1:10 PM Nils Bruin wrote: > > On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote: >> >> 1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific >> imports > > > I'm not sure whether I'm a fan of the "all" packages (for one thing, they >

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Friday, September 24, 2021 at 1:12:38 PM UTC-5 William Stein wrote: > I assume you are talking about the official binaries that are distributed > on Sagemath.org. Fortunately, the Sage binaries on > MacOS that are produced by the conda-forge devs are not total crap. > William, There are

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Mon, 27 Sep 2021, 00:01 Volker Braun, wrote: > On Sunday, September 26, 2021 at 11:34:33 PM UTC+2 dim...@gmail.com wrote: > >> I don't really see how homebrew is different from a rolling Linux distro. >> > > Homebrew doesn't come from the OS vendor. No automatic security updates. > There is

[sage-devel] Re: Refactoring/modularization work on the Symbolic Ring

This has just been merged in 9.5.beta2. On Tuesday, August 24, 2021 at 11:05:41 PM UTC-7 Matthias Koeppe wrote: > https://trac.sagemath.org/ticket/32386 proposes to merge the pynac > sources as src/sage/symbolic/ginac > into the Sage source tree. This

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Sunday, September 26, 2021 at 11:34:33 PM UTC+2 dim...@gmail.com wrote: > I don't really see how homebrew is different from a rolling Linux distro. > Homebrew doesn't come from the OS vendor. No automatic security updates. There is no package management where the admin can look up if any

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On Sun, Sep 26, 2021 at 12:53 PM Volker Braun wrote: > On OSX I don't feel comfortable recommending anyone to run a script as > root so homebrew can barf random files into the filesystem. For security > and maintainability we really need to be able to install Sage without > having unsigned and

[sage-devel] Re: Refactoring tasks in the Sage library to support modularization

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,

[sage-devel] Re: Refactoring tasks in the Sage library to support modularization

On Sunday, September 26, 2021 at 1:10:21 PM UTC-7 Nils Bruin wrote: > On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote: > >> >> *3. Break up Cython modules that depend on several C/C++ libraries >> simultaneously* >> >> An example is sage.matrix.misc, which depends on both

[sage-devel] Re: Refactoring tasks in the Sage library to support modularization

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

[sage-devel] Re: Refactoring tasks in the Sage library to support modularization

On Sunday, September 26, 2021 at 1:10:21 PM UTC-7 Nils Bruin wrote: > On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote: > >> *1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific >> imports* >> > > I'm not sure whether I'm a fan of the "all" packages (for

[sage-devel] Re: Refactoring tasks in the Sage library to support modularization

On Sunday, September 26, 2021 at 1:10:21 PM UTC-7 Nils Bruin wrote: > On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote: > >> *2. Do not import CLASS just to run an isinstance(..., CLASS); likewise, >> remove uses of is_CLASS functions* >> > >> Instead, create abstract base

[sage-devel] Re: Refactoring tasks in the Sage library to support modularization

On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote: > *1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific > imports* > I'm not sure whether I'm a fan of the "all" packages (for one thing, they make proper use of "lazy_import" a lot harder, but importing

[sage-devel] Refactoring tasks in the Sage library to support modularization

*1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific imports* This pattern in our Sage library code blocks modularization. In particular, imports from sage.rings.all, sage.modules.all, sage.misc.all, sage.categories.all, sage.matrix.all must be avoided because

[sage-devel] Re: #32532 - removing gcc and gfortran spkgs

On OSX I don't feel comfortable recommending anyone to run a script as root so homebrew can barf random files into the filesystem. For security and maintainability we really need to be able to install Sage without having unsigned and effectively unversioned dependencies. My suggestion would be