unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stephen Christie <spc@e.email>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: mail@ambrevar.xyz,guix-devel@gnu.org
Subject: Re: A plan for parameterized packages
Date: Tue, 17 Nov 2020 13:13:44 -0500	[thread overview]
Message-ID: <3E722E84-E8E7-4A52-B410-0A424963CA57@e.email> (raw)
In-Reply-To: <87r1osov9b.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4324 bytes --]

Ludo,

The self.options["openssl"].shared does set the option for openssl, but this is not different than providing `-o openssl:shared` on the command line; it uses this to determine which package was actually requested. Conan packages are also non-configurable in the end, stored as the hash of it's name and parameters. This is probably done while calculating the tree before installing/building everything, but once that tree is calculated, it is fixed.

Besides parameters determining the hash of the package, OpenSSL/2.1@memsharded/testing and openssl/1.0.2u are most certainly separate packages. Conan has this name/version@username/channel structure to help find alternatives (semver is supported), but otherwise those are completely different.

On November 17, 2020 10:31:12 AM EST, "Ludovic Courtès" <ludo@gnu.org> wrote:
>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’.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 4833 bytes --]

  reply	other threads:[~2020-11-17 18:23 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
2020-11-17 18:13   ` Stephen Christie [this message]
  -- 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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E722E84-E8E7-4A52-B410-0A424963CA57@e.email \
    --to=spc@e.email \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=mail@ambrevar.xyz \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).