From: "Ludovic Courtès" <ludo@gnu.org>
To: Stephen Christie <spc@e.email>
Cc: guix-devel@gnu.org
Subject: Re: A plan for parameterized packages
Date: Tue, 17 Nov 2020 16:31:12 +0100 [thread overview]
Message-ID: <87r1osov9b.fsf@gnu.org> (raw)
In-Reply-To: <8BB50B81-762F-4701-8A60-AAC323E4324A@e.email> (Stephen Christie's message of "Tue, 17 Nov 2020 09:25:37 -0500")
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’.
next prev parent reply other threads:[~2020-11-17 15:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 14:25 A plan for parameterized packages Stephen Christie
2020-11-17 15:31 ` Ludovic Courtès [this message]
2020-11-17 18:13 ` Stephen Christie
-- strict thread matches above, loose matches on Subject: below --
2020-11-15 16:33 Ludovic Courtès
2020-11-15 17:30 ` Nicolò Balzarotti
2020-11-15 17:40 ` Nicolò Balzarotti
2020-11-15 17:44 ` Pierre Neidhardt
2020-11-15 18:09 ` zimoun
2020-11-16 11:50 ` Ludovic Courtès
2020-11-16 12:03 ` Pierre Neidhardt
2020-11-16 14:05 ` zimoun
2020-11-15 17:37 ` zimoun
2020-11-16 11:54 ` Ludovic Courtès
2020-11-15 18:51 ` Taylan Kammer
2020-11-15 20:46 ` Danny Milosavljevic
2020-11-15 21:16 ` zimoun
2020-11-15 21:24 ` raingloom
2020-11-16 1:54 ` Ryan Prior
2020-11-18 1:30 ` Denis 'GNUtoo' Carikli
2020-11-20 11:39 ` Ludovic Courtès
2020-11-20 14:38 ` zimoun
2020-11-20 19:44 ` Christopher Baines
2020-11-16 14:51 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r1osov9b.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=spc@e.email \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.