Re: A plan for parameterized packages

2020-11-17 Thread Stephen Christie


> Hi Pierre,

> Pierre Neidhardt  skribis:

> > One of the biggest struggle we had when discussing it was figuring out
> > what to do about parameter propagation across dependencies.

> > For instance, what if we want to build "all packages without X support"?
> > This means that the parameter must traverse all inputs recursively if we
> > don't want to drag X indirectly.

> > If I understand your change correctly, the patch is only applying
> > parameters to the given package and it's not propagated to the inputs,
> > is that correct?

> That’s correct: in this patch set parameters are per-package, and I
think it’s easier to start simple, but we could implement what you
describe without too much hassle I think.

> For example, you’d type ‘--with-parameters=x11=false’, and that’d be
applied to all the packages that have an ‘x11’ parameter.

> Ludo’.

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.

If you would, please forward this to the mailing list that this message was 
from, as I am not currently on that list.

Sincerely,
Stephen Christie


Re: A plan for parameterized packages

2020-11-17 Thread Stephen Christie
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"  wrote:
>Hi Stephen,
>
>(+Cc: guix-devel@gnu.org.  You can post without being subscribed.)
>
>Stephen Christie  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.