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’.