Hi Stephen,
(+Cc: guix-devel@gnu.org. You can post without being subscribed.)
Stephen Christie <spc@e.email> skribis:
I have done a lot of work with the Conan package manager, a c++
language package manager, that has grown in capability. It is not
fully functional, but works on the hash of the key parameters of the
package (name, version, etc.) to find the right reproducible
binary. Two important parameters are "options" and "settings".
Options are per-package, and generally affect none below it. You can
specify defaults for the options in the package, and also call for
specific options on dependencies in package "recipes". There are also
ways to define incompatibilities and substitutes. On the command line,
you can specify options with -o,--options, with no namespace needed
for the package you are installing, and package:option to specify for
other packages pulled in. I prefer this syntax to all the equal signs
you proposed (though I defer if this is standard throughout
Guix/Guile)
Settings are more "system-wide", though being a language package
manager, it does not have a "system". The same settings are applied to
the whole tree during an install, and are usually things like
compiler, architecture, and build type. These settings are chosen
through a profile file, of which there is a default generated for a
given computer. Settings can also be set at the command line during
install with -s,--settings, but of course there is no namespacing.
https://docs.conan.io/en/latest/mastering/conditional.html
I think there is a lot of good stuff in Conan that Guix could learn
from. It's a lot closer in architecture than any of the traditional
system package managers.
Thanks for sharing Conan’s perspective on these issues!
The settings/options distinction looks like a useful one. Like Pierre
suggested, it’d be nice to have options that apply to the whole graph in
addition to per-package options like I was focusing on.
Conan’s approach to conflicting options may not be applicable to Guix.
For instance, the manual above has this example:
def configure(self):
# …
if self.settings.os == "Windows":
self.options["openssl"].shared = True
def requirements(self):
# Or add a new requirement!
if self.options.testing:
self.requires("OpenSSL/2.1@memsharded/testing")
else:
self.requires("openssl/1.0.2u")
In Guix, instead of stating that OpenSSL 1.0.2u is required or that it
needs to include shared libraries, you’d actually depend on a variant of
OpenSSL that fulfills these constraints; by construction, you can be
sure you have the intended OpenSSL variant (generally speaking, a Guix
package dependency graph has zero degrees of liberty, unlike an
apt/Spack/Conan graph.)
As for the syntax… yeah, we could find a shorthand. :-) The verbosity
in the examples I gave partly stems from the fact that these are
per-package parameters, so you need to specify which package it applies
to. With “global” parameters, we could have, say:
guix install -P x11=false emacs
meaning that the ‘x11’ parameter will be set to #f in all the packages
that have such a parameter.
Thanks,
Ludo’.