[Top][All Lists]

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

Re: Collect guix profiles in single directory.

From: Leo Prikler
Subject: Re: Collect guix profiles in single directory.
Date: Wed, 08 Jan 2020 14:48:39 +0100
User-agent: Evolution 3.32.4

Hi Ludo,

Am Mittwoch, den 08.01.2020, 12:25 +0100 schrieb Ludovic Courtès:
> Hi Leo,
> Leo Prikler <address@hidden> skribis:
> > currently, our configuration is (more or less true to XDG)
> > scattered
> > around various places.  Even if one does not make use of more
> > advanced
> > features, one will at least have two profiles:
> > - ~/.config/guix/current
> > - ~/.guix-profile
> > If one does have more configuration data, the channels.scm must be
> > put
> > under ~/$XDG_CONFIG_HOME/guix/.  Note, that this need not be
> > ~/.config/guix, but most likely is.  If one wishes to use more than
> > one
> > profile, so as to keep the build times for each shorter, one has to
> > write custom code and can not rely on /etc/profile.
> > 
> > This is a proposal to change the current approach.  Instead of
> > splitting Guix config in a way that tries to conform to XDG, but
> > does
> > not really, I propose to use a single directory ~/.guix for all
> > configuration.
> > This includes:
> > - ~/.guix/channels.scm
> > - ~/.guix/channels (instead of ~/.guix/current, to match the name
> > channels.scm)
> > - ~/.guix/profile
> > - user-generated profiles
> To me, the most important aspect of your proposal is having all
> profiles
> in one place (Konrad proposed something similar recently, well, “last
> year.”  :-))
> Like I wrote then, ‘guix package --list-profiles’ was an attempt at
> making it easier to locate profiles, even if they’re not in the same
> directory, so that you can easily operate on them.  What Konrad noted
> is
> that this returns all the profiles, including
> ~/.config/guix/current-kind of profiles, which may be inconvenient.
That is certainly a convienient command, although not quite enough for
the purpose I had in mind.  Perhaps list-profiles could be extended
into its own command to allow for more filtering options on the command
line, including stuff like ‘--kind=(channel|package)’, ‘--prefix=DIR’,
and so on.

> I’m generally wary of enforcing arbitrary conventions, such as a
> specific directory to store all profiles, but at the same time I
> agree
> that this can be convenient, so I’m a bit split!
To be more clear, I do not want ~/.guix to be the ONLY directory where
profiles can be stored in.  Perhaps the title and initial post were
somewhat misleading in that regard.
However, I do want ~/.guix to be treated as the directory, where
necessary data is put in (i.e. channels and the default profile) and
where users can add their own profiles to be treated as if they were
the default profile.  
IOW, when looking at the examples of “Guix Profiles in Practice”, I do
not want to have to create ~/.guix-extra-profiles and ~/.guix-extra or
~/.guix-manifests, and neither do I want to set the associated
environment variables.  Rather, I want ~/.guix to serve both purposes.

As an example
--8<---------------cut here---------------start------------->8---
for profile in "$GUIX_EXTRA_PROFILES"/*; do
  guix package --profile="$profile" --manifest="$HOME/.guix-
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
for profile in $(guix list-profiles --prefix=$HOME/.guix --
kind=package); do
  guix package --profile="$profile" --manifest="$profile-manifest.scm"
--8<---------------cut here---------------end--------------->8---
the latter of which I would personally much prefer.

> Also, such a change would need a transition plan: what does ‘-p’
> become, etc.
Given my above considerations, I would not want to change the behaviour
of ‘-p’.  Perhaps one could add a convenience notation for
$GUIX_PROFILE_DIR/profile, but given that ~/.guix/profile is not too
hard to type, not doing that would probably be the better option.



reply via email to

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