Prefer Linux package manager over linuxbrew; add nix detection

[tobiasdiez]

If brew is installed on Linux, Sagemath thinks this is the primary package manager and, e.g., configure suggests to run brew ... to install new packages. However, linuxbrew is untested as a platform for Sage, and so this is not a good idea.

We change build/bin/sage-guess-package-system so that brew is only tested after the Linux package managers.

We also add a detection for nix-env.

CC: @mkoeppe @collares @jplab

Component: build: configure

Author: Matthias Koeppe

Branch/Commit: u/mkoeppe/prefer_linux_package_manager_over_linuxbrew @ 9af33a1

Issue created by migration from https://trac.sagemath.org/ticket/32753

[dimpase]

comment:2

I now see this in our gitpod.

[mkoeppe]

Branch: u/mkoeppe/prefer_linux_package_manager_over_linuxbrew

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

Commit: 90f7ced

[mkoeppe]

Description changed:

--- 
+++ 
@@ -1,3 +1,7 @@
-If brew is installed on Linux, Sagemath thinks this is the primary package manager and, e.g., configure suggests to run brew xyz to install new packages.
+If brew is installed on Linux, Sagemath thinks this is the primary package manager and, e.g., `configure` suggests to run `brew ...` to install new packages. However, linuxbrew is untested as a platform for Sage, and so this is not a good idea.
 
-Probably build/bin/sage-guess-package-system should be changed so that brew is only tested after the Linux package managers. 
+We change `build/bin/sage-guess-package-system` so that `brew` is only tested after the Linux package managers. 
+
+We also add a detection for `nix-env`.
+
+

[mkoeppe]

comment:4

For nix, do we need to check whether a nix environment is active, like we do for conda?

---

New commits:

04f9749	build/bin/sage-guess-package-system: check linuxbrew after linux package managers because it is untested
90f7ced	build/bin/sage-guess-package-system: Check for nix

[collares]

comment:5

To be honest with you, I have never used nix-env (the manual offers a declarative path and a nix-env path, and strongly suggests nix-env is the worst of the two alternatives). I think supporting nix-env is valid, but given my lack of experience with it I am not sure what the workflow would be in this case. You can certainly install packages with nix-env in your "default profile", and the executables would be in PATH without having to activate an environment.

People who follow the declarative approach and want to build Sage from source would bypass nix-env and write a derivation (a declarative recipe, basically) to pull in the required dependencies, and then pass this to nix-shell to obtain an ephemeral virtualenv-like environment with those deps available. Or, instead of writing the derivation themselves, they could also use Nixpkgs's Sage derivation to get the same build environment we use. Either way, they would be able to build Sage from Git sources using Nix packages for the dependencies, but nix-env would be none the wiser.

It would be useful to know a few things so I can understand how this fits into the Nix model: Is it just for printing a command to install dependencies? Or does it query installed packages as well? What happens if Singular (say) just exists on PATH but nix-env doesn't report it as installed? Pointing me to the relevant source file would be enough, no need to answer in detail. Thanks!

[mkoeppe]

comment:6

Replying to @collares:

People who follow the declarative approach and want to build Sage from source would bypass nix-env and write a derivation (a declarative recipe, basically) to pull in the required dependencies, and then pass this to nix-shell to obtain an ephemeral virtualenv-like environment with those deps available. Or, instead of writing the derivation themselves, they could also use Nixpkgs's Sage derivation to get the same build environment we use.

It would be great to have instructions how to do Sage development using nixpkgs in our installation manual.

Other than figuring out how to provision a nix environment with packages on top of the nixos/nix Docker image (so I can say tox -e docker-nixos-standard), I have no experience with nix.

By the way, I am getting the error:

Step 6/46 : RUN  nix-env --install  gd iml m4ri gfan singular mpfi cmake symmetrica flintqs freetype cddlib libbraiding brial ppl sympow zn_poly readline R sqlite tachyon giac m4rie blas lapack ntl glpk fflas-ffpack libmpc gsl boost nauty binutils gnumake gnum4 perl python3 gnutar bc gcc bash flint arb pari cliquer libhomfly openssl gengetopt planarity lrcalc palp ecm givaro ecl eclib lcalc rankwidth qhull gettext autoconf automake libtool pkg-config
 ---> Running in 0dcbda1f2003
error: selector 'libhomfly' matches no derivations

so it may be that some work on the nix.txt files is needed.

[mkoeppe]

comment:7

Replying to @collares:

It would be useful to know a few things so I can understand how this fits into the Nix model: Is it just for printing a command to install dependencies?

Yes, it's for the system package advice that is printed at the end of a configure run.

The code for this is in build/bin/sage-print-system-package-command.

[mkoeppe]

comment:8

Replying to @collares:

What happens if Singular (say) just exists on PATH

configure only checks what is available in PATH.

For packages where we don't find a system package in this way, if there is system package information in build/pkgs/*/nix.txt for the package, we issue the system package advice. No package manager queries are done -- this is all left to the user.

(This is a design principle for this code -- it does not attempt to take care of system package installation tasks for the user; instead it only informs/educates the user about possible commands.)

[collares]

comment:9

Thanks for the information, this is very helpful! So, yeah, I think recommending nix-env is fine, since people who use the declarative approach can just copy and paste the list of packages into their derivations.

As for the libhomfly error: The preferred way to install packages using nix-env is nix-env -f '<nixpkgs>' -iA m4ri libhomfly (say). The -A flag specifies a saner way of finding the relevant package; in this case, the -A-less version caught a typo in the Nix package. I've submitted a PR to fix it in Nixpkgs, but ideally the nix-env invocation would be switched to something like the command I mentioned above.

I will try to write some docs for Sage development with nixpkgs as part of the Sage 9.6 release.