Re: Profiles/manifests-related command line interface enhancements

[Pierre Neidhardt]

Ludovic Courtès <address@hidden> writes:

> Another way is:
>
>   eval `guix package --search-paths=prefix`
>
> or similar.

Note that this suffers from the shell compatibility issue, e.g. it won't
work with Fish / Eshell.

> Another one is:
>
>   guix environment …

This is a bit different since it spawns a subshell.
Depends on the use case.

> The MANPATH issue is orthogonal so I don’t think we should bring it up
> in this context.  See <https://issues.guix.gnu.org/issue/22138> for
> context.

Oh, this is exactly it!  Thanks for the link, I had no clue this had
been under discussion... since 2015 O.o :)

>> - All commands that accept manifests should be able to compose manifests
>>   by passing multiple =--manifest FILE= options.
>
> Do you have a use case?  :-)
>
> Sounds like something quite easy to do but I’ve never heard anyone
> request it before so I’m curious.

I'm actually surprised you find it surprising! :)
I can think of Simon, maybe Konrad(?) and myself who mentioned it
before.

Examples:

- `guix pack` can only pack ` manifest at a time.  Impossible to combine
  2 manifests.

- Same for guix weather if you want to avoid calling guix weather
  multiple times in a row.

- `guix environment` can work around this limitation by calling the
  manifest from the generated subshells.  It's not super convenient, and
  it does not work for scripts.  For instance, we can't do this at the moment:

   guix environment -m manifest1 -m manifest2 -- my command line...

I'm sure we can come up with tons of examples :)

>> - Use a default manifest by default with =guix install= and =guix
>>   remove=.  This way would basically get rid of "ad-hoc" profiles which
>>   has so many flaws (non-reproducible, non-trackable, etc.).
>
> Ambitious!
>
> Note that “ad-hoc” profiles (imperatively-managed profiles) contain
> provenance info in their ‘manifest’ file, so it’s not black and white.

I actually never noticed this :p

>> Last, one that's at the Scheme level:
>>
>> - A Scheme function to create a manifest for the necessary inputs of a
>>   package, like =guix environment PACKAGE= does.  (Maybe it's already 
>> possible?)
>
> Like ‘specifications->manifest’?

Can specifications->manifest do this?

Concrete example:  You want a profile to work on IceCat, so you need a
manifest that has all the necessary inputs required to work with Icecat.
How can we automate the generation of the manifest?

> Note that another option is to overhaul ‘guix environment’ like David
> proposed a while back:
>
>   https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html

Nice thread, lots of good ideas in there.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

signature.asc
Description: PGP signature