On 20 April 2024 19:34:49 BST, Matthias Koeppe <matthiaskoe...@gmail.com> wrote:
>On Saturday, April 20, 2024 at 12:56:30 AM UTC-7 Martin R wrote:
>
>do I understand correctly that common lisp (via maxima) is the main
>dependency that prevents sagemath from being pip-installable?
>
>
>No.
>
>For one, SageMath is already pip-installable.
>That was one of the first deliverables of the modularization project,
>completed in 2021.
>See
>https://wiki.sagemath.org/ReleaseTours/sage-9.4#Alternative_installation_methods_using_pip
>
>It's documented in our README:
>https://github.com/sagemath/sage/blob/develop/README.md#alternative-installation-using-pypi
>
>However, installing Sage in this way is equivalent to installing the full
>Sage distribution from source in the normal way.
No, it is not equivalent, far from it. One can read on
<https://pypi.org/project/sagemath-standard/#description>
Building sagemath-standard has a large number of system packages as
prerequisites. See
https://doc.sagemath.org/html/en/installation/source.html#linux-recommended-installation
for partial lists for various systems.
That is, many packages are not built. What's being built is not a Sage
distribution, it is sagelib.
> (This is
>what https://pypi.org/project/sage-conf/ does.)
>It takes very long. This alone makes it simply not suitable as a dependency
>of other pip-installable projects.
>
>
>In another message, you asked:
>> 1.) Is there an example for someone who did not want to use sage because
>of some dependency of the math library? Or at least a possible reason?
>[...] But this begs the question: who profits from cutting the math library
>into pieces (which look very arbitrary to me and have a curious emphasis on
>discrete math topics)?
>
>If you do allow me another example from discrete math: Sage has a lot of
>very good code in "sage.graphs" that provides functionality that is not
>available from other Python libraries.
>
>But to potential projects that would need this functionality, the
>proposition to have to depend on the monolithic project SageMath, with
>hours of compilation time and/or dependencies on system packages that are
>obviously unrelated to the needed functionality (boost, brial, ecl, eclib,
>ecm, fflas_ffpack, flint, libgd, gap, giac, givaro, glpk, gmp, gsl, iml,
>lcalc, libbraiding, libhomfly, libpng, linbox, m4ri, m4rie, mpc, mpfi,
>mpfr, ntl, pari, rw, singular, symmetrica), is simply a showstopper.
>
This is not true, either. First, a lot of these packages that you list are
available on systems, and thus there is no need to build them.
(To "but macOS?" I have a reply: "ask Apple to provide you a package manager,
it's the best OS, right, you pay for it a lot of money, or learn to use
Homebrew like Mac users usually do...")
Anyway, a normal Python pypi-installable package comes with binary wheels, i e.
things are pre-built, and it's merely matter of downloading these to get a
functional package. Few minutes on a fast network, not hours.
By choosing to be an exception in the Python world,
Sage obviously does something quite wrong.
Dima
--
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/2D37D4FE-4FBC-4F65-8E7E-27B036B2E4C1%40gmail.com.
