As of today, it is plausible that such situations still exist.
a) If a critical bug is discovered, we can patch it and don't have to rely on people and infrastructure "outside the project" to fix things for us.
Of course, we have been very lucky that packagers for many distributions have been consistently highly engaged with the project; but this is not something that we can take for granted.
b) And, of course, more Sage developers can become contributors to the packaging communities; but there is the real danger that taking care of both upstream development *and* downstream packaging for the same project can lead to developer burnout.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GCTmMFcJw_mw2_UJKu4H6nvhOCJ0t5sbUoT1a090sh2aw%40mail.gmail.com.
To what extent does or could Conda with a little more work solve most
of these problems? [...]
I also think this section
https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental
called "Using conda to provide all dependencies for the Sage library
(experimental)" is pretty exciting!
In any case, I think that migrating from "Sage the distribution" to
solving a lot of the misc environment issues
via conda would be very analogous to switching to Github, instead of
maintaining our own issue tracker.
> and took 5.8GB disk instead of the 3GB disk of the Sage mac app).Yes, conda packages usually come with batteries included which means packages come with theiroptional build time dependencies installed. That's usually not a big deal for other packages, butSage is special in that it has tons of dependencies.
As an example, how old of a Windows computer could one install the current Sage on? I mean from scratch - not necessarily from source - using WSL, which I guess is now the main supported way to do so?
What about the Cygwin installer - does it still exist in older versions on sagemath.org mirrors, what does that support? How easy is it for someone who does NOT know about compiling to install Sage on a not-too-recent Windows machine?
One thing that might help all of this is having older versions of Sage *binaries* for such platforms readily available for download (as many of our upstream packages in fact do). I don't think we are.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0a85f27c909f8d8f185801af2228e6331bcad544.camel%40orlitzky.com.
On Thu, Apr 27, 2023 at 1:00 PM Michael Orlitzky <mic...@orlitzky.com> wrote:
[...] Gentoo Prefix [...] Nix [...]
Guix and spack could also work.
I guess there are several requirements we need1. Support for all major OS/architecture combinations2. Easy to build for rare OS/architecture combinations3. Possible to install as a non-root user4. Binaries are available for non-rootAFAIK, there's no package manager that has all 4 above and we will have to pick whichrequirements are more important than others.
(I'm planning upgrades in the next year or two, but it will be to
relatively low power RISC-V hardware. There are moral, legal,
environmental, and other non-financial reasons why people use "old"
hardware. But of course the financial reasons are very real too.)
I guess there are several requirements we need1. Support for all major OS/architecture combinations2. Easy to build for rare OS/architecture combinations3. Possible to install as a non-root user4. Binaries are available for non-root
The test suite can take another full day to run -- some of
that is useful, but a lot is not. This is the biggest impediment to the
use and development of sage on an old system.
The next in line will be jupyter and friends.
In this PR (https://github.com/sagemath/sage/pull/35585), the three optional packagesinfo, valgrind, rubiks are switched from our custom installation scripts to a (binary) installation from conda-forge.
This drops platform support for 32-bit Linux (see https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help) for these optional packages. We will need a decision if this OK.
A precedent for phasing out support for a platform in this way was set in 2021 (Sage 9.4), when we dropped support for optional packages on old Linux systems with GCC 4.x toolchains (https://wiki.sagemath.org/ReleaseTours/sage-9.4#Support_for_optional_packages_on_systems_with_gcc_4.x_dropped).
On Saturday, April 29, 2023 at 12:28:22 AM UTC-7 Matthias Koeppe wrote:
That's now https://github.com/sagemath/sage/pull/35585 (needs review); starting with optional packages, not standard infrastructure packages though.
On Saturday, April 29, 2023 at 12:14:56 AM UTC-7 Volker Braun wrote:
+1 to just using conda for all basic infrastructure packages if the host doesn't have them. Just put a conda env in the PATH and done.
I have a naive question about the installation process. It is naive because I have read only part of the thread and linked PRs:
Some of the packages in #35585 (e.g. pandoc) are rather popular,
and usually have support in a superset of Linux distros supported
by Sage. Should `sage -i pandoc`, at least in an interactive
session, first recommend to install it from the distro, and not
default to conda? For example, if a user wants to customize an
init file of the package or already installed most dependencies of
a package from the distro, then the installing from the distro
might be better. Have this been discussed before?
Regards,
TB
On 29/04/2023 23:10, Matthias Koeppe wrote:
In this PR (https://github.com/sagemath/sage/pull/35585), the three optional packagesinfo, valgrind, rubiks are switched from our custom installation scripts to a (binary) installation from conda-forge.
I have a naive question about the installation process. It is naive because I have read only part of the thread and linked PRs:
Some of the packages in #35585 (e.g. pandoc) are rather popular, and usually have support in a superset of Linux distros supported by Sage. Should `sage -i pandoc`, at least in an interactive session, first recommend to install it from the distro, and not default to conda?
Should `sage -i pandoc`, at least in an interactive session, first recommend to install it from the distro, and not default to conda?
On Saturday, April 29, 2023 at 1:45:31 PM UTC-7 TB wrote:Should `sage -i pandoc`, at least in an interactive session, first recommend to install it from the distro, and not default to conda?
I wouldn't want "./sage -i pandoc" to ask for confirmation, but we could certainly have it print a note first and then users can ^C out of it if they want to try that.