guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Profiles/manifests-related command line interface enhancements


From: Ludovic Courtès
Subject: Re: Profiles/manifests-related command line interface enhancements
Date: Wed, 06 Nov 2019 17:42:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Pierre Neidhardt <address@hidden> skribis:

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

That can be fixed, as proposed in
<https://issues.guix.gnu.org/issue/36021>.

>> Another one is:
>>
>>   guix environment …
>
> This is a bit different since it spawns a subshell.

Not if you do “-- some command”.

>>> - 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 :)

I understand what it is we cannot do; I just hadn’t felt the need for
it.  But yeah, let’s do that!  :-)

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

It’s sort of a “hidden” feature waiting to be put to good use.  :-)

>>> 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?

Ah, that no.  But (guix scripts environment) has
‘package-environment-inputs’, which does exactly that, and I guess we
could expose it and document it.

More generally, ‘guix environment’ was initially designed in a quite
monolithic fashion, and I think we could expose its functionality in
sizable bites.  For instance, Dave suggested long ago exposing an
<environment> data type, and that’s one thing that could be very useful.

Thanks for starting this insightful brainstorming session!  :-)

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]