Dear Matthias!
You mentioned several times, that discoverability is an important aspect.
Do you have any evidence to support that?
Wouldn't people in the python world who need a serious amount of math know
of sage anyway, and then, if they cannot rely on all of sage because that
is too large, use, for example, `citation.get_systems` to see whether they
can do without some dependencies?
I don't see how splitting the sage math library into pieces helps
discoverability. I admit, however, that I cannot really think of any
serious use of any of the functionality of sage outside of math, where
people would know that what they need is, say combinatorics or graph
theory. I guess it would be quite insane to install sage or parts of sage
to get an implementation of a particular algorithm in a non-math
environment.
Martin
On Wednesday 24 April 2024 at 03:58:35 UTC+2 Dima Pasechnik wrote:
>
>
> On 23 April 2024 19:13:44 BST, Matthias Koeppe <matthia...@gmail.com>
> wrote:
> >On Tuesday, April 23, 2024 at 11:06:12 AM UTC-7 Dima Pasechnik wrote:
> >
> >
> >
> >On 23 April 2024 18:41:34 BST, Matthias Koeppe <matthia...@gmail.com>
> >wrote:
> >>*$ git blame src/sage/combinat//designs/block_design.py*
> >>
> >>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 65)
> >>lazy_import('sage.libs.gap.libgap', 'libgap')
> >>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 66)
> >>lazy_import('sage.matrix.matrix_space', 'MatrixSpace')
> >>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 67)
> >>lazy_import('sage.modules.free_module', 'VectorSpace')
> >>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 68)
> >>lazy_import('sage.rings.finite_rings.finite_field_constructor',
> >>'FiniteField')
> >>
> >>What you see there is the result of work in the modularization project,
> >>using one of the techniques documented
> >>in
> >
> https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#dependencies-and-distribution-packages
>
> >>("Reducing module-level run-time dependencies:") to reduce dependencies
> or
> >>to make dependencies milder.
> >
> >The problem is that without these imports, lazy or not, this module is
> >basically useless.
> >
> >
> >That's correct, but that's not a "problem".
>
> It is a problem, because such a module doesn't do what is says on the
> label.
> Basically such a module is a semi-random part of sagelib, and it would not
> be fully functional until one installs a good chunk, probably well over
> half, of sagelib.
>
> I am not saying it is totally useless, this sort of partition, but I don't
> see the point of distributing such pieces, as Python wheels, as something
> useful on their own.
>
> Application builders - who, according to Marc, are the only ones to get
> benefits from this design - can just as well build the needed part of
> sagelib from source, they don't need these barely useful wheels.
>
>
>
> >
> >It's part of a deliberate design, explained in detail in my 2023-06
> >sage-devel posts.
> >
> >From "*Modularization project: IV. The rules*"
> >(https://groups.google.com/g/sage-devel/c/ozh-7ZZ848s):
> >*3.* Distribution packages declare build dependencies and runtime
> >dependencies
> ><
> https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#dependencies-and-distribution-packages>
>
> (on
> >other Python distribution packages). These two can be entirely unrelated
> to
> >each other. In addition to the runtime dependencies, it is possible to
> >declare extra dependencies – either those necessary for running tests
> ><
> https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#doctest-only-dependencies>
>
> or
> >for providing advertised
> ><
> https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies
> >
> >extra
> ><
> https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies
> >
> >features
> ><
> https://sagemath-tobias.netlify.app/developer/packaging_sage_library.html#other-runtime-dependencies>.
>
>
> >But there is no such thing as an "optional build dependency" or
> >"conditional compilation". The set of modules that form a distribution
> >package is static. There is no place in the name (or metadata) of a wheel
> >package that could indicate different "configurations".
> >
> >*4. *As a result of 3, it is possible to create distributions that
> contain
> >some modules that cannot be imported because some of their dependencies
> are
> >missing. That's OK; they can become importable simply by the presence of
> >other distributions, in particular those declared as extra dependencies.
> >All of this is discovered at the time of importing a module; there is no
> >ahead-of-time linking step of any sort.
> >
> >From "*Modularization project: V. The blocs*"
> >(https://groups.google.com/g/sage-devel/c/kiB32zP3xD4):
> >*We should not attempt to define a distribution package for every
> possible
> >community or subfield of mathematics that Sage supports.*
> >The proposed design instead introduces 3 types of distribution packages:
> >[...]
> >Each of the distribution packages can define a list of extras (nicknames
> >for sets of other distribution packages that provide additional
> advertised
> >features). When using pip to install a distribution, users can use square
> >bracket notation to add (adjoin?) these extras.
> >
> >
>
--
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/b1472a7d-732b-4bb3-ac20-934faa9fcc1en%40googlegroups.com.
