“Guix Profiles in Practice”

“Guix Profiles in Practice”

[Ludovic Courtès]

Hello Guix!

Here’s a new blog post by Pierre Neidhardt entitled “Guix Profiles in
Practice”:

  https://guix.gnu.org/blog/2019/guix-profiles-in-practice/

A great discussion on the benefits of manifests and on ways to manage
several profiles!

Ludo’.

Re: “Guix Profiles in Practice”

[Thompson, David]

On Fri, Oct 25, 2019 at 6:57 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hello Guix!
>
> Here’s a new blog post by Pierre Neidhardt entitled “Guix Profiles in
> Practice”:
>
>   https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
>
> A great discussion on the benefits of manifests and on ways to manage
> several profiles!

Great article!

I spotted a typo in the first paragraph: "on a same system" should be
"on the same system."

The section below reminds me about some unfinished work from back when
I wrote 'guix environment':

    Eventually, we set to work on that project again, so we run guix
    environment -m manifest.scm. But now we have to wait for Guix to
    build and install stuff!

This is indeed a frustration.  It takes a bunch of extra switches to
have 'guix environment' create a profile and even I don't bother with
it, just opting to build a new profile if I've upgraded guix since the
last time I worked on the project.  This gets me into trouble when I
upgrade guix and decide that I want to work on the project while I'm
somewhere with no network connection or too slow of a connection to
download everything in a reasonable time.  It has happened to me
multiple times while commuting by train.

'guix environment' is a very composable command, and it's not clear to
me how I would add the stuff I want onto it and it's even less clear
if it's a good idea.  Probably not.  So, I wonder if maybe a new
subcommand, say 'guix develop', could address this common development
use-case while allowing 'guix environment' to continue being the swiss
army knife that it is.  Some simple naming conventions could make this
tool "just work."  Running 'guix develop' would check for a profile
symlink with some canonical name, for example '.guix-develop-profile'.
If it exists, it applies the environment variables and spawns a
subshell.  If it doesn't exist, it looks for a 'develop.scm' file
(canonical name TBD), builds the profile, symlinks it to
'.guix-develop-profile', and then does the prior steps.  The tool
would provide a mechanism to update, etc. and it could even be
expanded later to spawn services like databases.

- Dave

Re: “Guix Profiles in Practice”

[Pjotr Prins]

On Fri, Oct 25, 2019 at 12:36:01PM -0400, Thompson, David wrote:
> On Fri, Oct 25, 2019 at 6:57 AM Ludovic Courtès <ludo@gnu.org> wrote:
> >
> > Hello Guix!
> >
> > Here’s a new blog post by Pierre Neidhardt entitled “Guix Profiles in
> > Practice”:
> >
> >   https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
> >
> > A great discussion on the benefits of manifests and on ways to manage
> > several profiles!
> 
> Great article!

I agree. One useful thing not mentioned in there is, that before
loading a profile, it may be worthwhile to empty the shell with

  env -i /bin/bash --login --noprofile --norc

  . ~/opt/my-tools-profile/etc/profile

so no existing shell variables may pollute your beautiful setup. 

Pj

Re: “Guix Profiles in Practice”

[Jonathan Frederickson]

On 10/25/19 12:36 PM, Thompson, David wrote
> 'guix environment' is a very composable command, and it's not clear to
> me how I would add the stuff I want onto it and it's even less clear
> if it's a good idea.  Probably not.  So, I wonder if maybe a new
> subcommand, say 'guix develop', could address this common development
> use-case while allowing 'guix environment' to continue being the swiss
> army knife that it is.  Some simple naming conventions could make this
> tool "just work."  Running 'guix develop' would check for a profile
> symlink with some canonical name, for example '.guix-develop-profile'.
> If it exists, it applies the environment variables and spawns a
> subshell.  If it doesn't exist, it looks for a 'develop.scm' file
> (canonical name TBD), builds the profile, symlinks it to
> '.guix-develop-profile', and then does the prior steps.  The tool
> would provide a mechanism to update, etc. and it could even be
> expanded later to spawn services like databases.

I love this idea, though I'd like to expand upon that a bit. There's 
another tool in the Python world that does something similar called 
Pipenv. The gist of it is:

Pipfile: analogous to a Guix manifest
Pipfile.lock: analogous to a Guix manifest + channel spec (this file 
contains precisely specified dependency versions)
~/.local/share/virtualenvs/<venv name>: Generated virtualenvs (analogous 
to a Guix profile, of course)

You work with these as follows:

$ pipenv install
^ creates a virtualenv with packages from Pipfile.lock (if it exists) 
otherwise creates a virtualenv with packages from Pipfile and (by 
default) creates Pipfile.lock
$ pipenv lock
^ resolves dependencies for packages in Pipfile and (re)creates Pipfile.lock
$ pipenv shell
^ spawns a subshell in the project's virtualenv

It occurs to me that you could nicely replicate this behavior in Guix by 
doing much the same thing; have a convenience command that reads a 
manifest with a well-known filename, creates profiles in a well-known 
location, and generates a channel spec (probably the current version of 
Guix the first time it's run). The end result is that a user could clone 
a project with both a manifest and channel spec and end up in the same 
environment by just running 'guix develop'.

Re: “Guix Profiles in Practice”

[Jonathan Frederickson]

On 10/25/19 8:34 PM, Jonathan Frederickson wrote:
> 
> Pipfile: analogous to a Guix manifest

Something I missed here; a Pipfile isn't *quite* analogous to a Guix 
manifest because it also contains the PyPI repo URLs to find those 
packages. So I think a Pipfile analogue would need a new record type 
containing both the repo URLs (without commit hashes) and the manifest.

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

"Thompson, David" <dthompson2@worcester.edu> writes:

> Great article!

Thanks! :)

> I spotted a typo in the first paragraph: "on a same system" should be
> "on the same system."

I can fix it.  Out of curiosity, why is it wrong?  "All users on a
system..."  is correct, "All users on a given system" too, so I wonder
why "on a same system" would not be.  What I meant here is "the same
unspecified system".

> 'guix environment' is a very composable command, and it's not clear to
> me how I would add the stuff I want onto it and it's even less clear
> if it's a good idea.  Probably not.  So, I wonder if maybe a new
> subcommand, say 'guix develop', could address this common development
> use-case while allowing 'guix environment' to continue being the swiss
> army knife that it is.  Some simple naming conventions could make this
> tool "just work."  Running 'guix develop' would check for a profile
> symlink with some canonical name, for example '.guix-develop-profile'.
> If it exists, it applies the environment variables and spawns a
> subshell.  If it doesn't exist, it looks for a 'develop.scm' file
> (canonical name TBD), builds the profile, symlinks it to
> '.guix-develop-profile', and then does the prior steps.  The tool
> would provide a mechanism to update, etc. and it could even be
> expanded later to spawn services like databases.

Indeed, while I worked on the article I was frustrated with the CLI, so
I wrote this Emacs "hack":

https://gitlab.com/emacs-guix/emacs-guix/issues/13

This is essentially what you propose, but to have it at the CLI level
would provide several benefits:

- More universal.
- Possibly more optimized (e.g. caching).



At the end of the article, I also talk about reproducibility, which is
currently quite cumbersome to deploy because of the need to refer to a
"specific guix channel checkout".

Konrad talked about how we could possibly improve the CLI to deal with
that as well:

https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00511.html

Both issues could be addressed the same way.

Cheers!

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Fri, Oct 25, 2019 at 12:36:01PM -0400, Thompson, David wrote:
>> On Fri, Oct 25, 2019 at 6:57 AM Ludovic Courtès <ludo@gnu.org> wrote:
>> >
>> > Hello Guix!
>> >
>> > Here’s a new blog post by Pierre Neidhardt entitled “Guix Profiles in
>> > Practice”:
>> >
>> >   https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
>> >
>> > A great discussion on the benefits of manifests and on ways to manage
>> > several profiles!
>> 
>> Great article!
>
> I agree. One useful thing not mentioned in there is, that before
> loading a profile, it may be worthwhile to empty the shell with
>
>   env -i /bin/bash --login --noprofile --norc
>
>   . ~/opt/my-tools-profile/etc/profile
>
> so no existing shell variables may pollute your beautiful setup. 

Nice tip, Pjotr!

We can add it to the cookbook.  Shall I add it to the blog article now
that it's published?

In https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00565.html
we discussed the possibility to remove a specific profile from the
environment, which would be a more general version of what you propose.
It currently has some shortcomings, but maybe we can fix them.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Alex Griffin]

On Fri, Oct 25, 2019, at 5:24 AM, Ludovic Courtès wrote:
> Here’s a new blog post by Pierre Neidhardt entitled “Guix Profiles in
> Practice”:
> 
>   https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
> 
> A great discussion on the benefits of manifests and on ways to manage
> several profiles!

Great article, Pierre! I've known for a while how to do all this, but I still just used one big profile. Following along with your article, I finally went ahead and split it up.

I noticed some typos though. This line has mismatched quotes:

> export MANPATH=/path/to/profile${MANPATH:+:}$MANPATH"

And this sentence is missing a couple words in the cookbook version:

> This means that the exact same profile can be anytime, with

-- 
Alex Griffin

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

"Alex Griffin" <a@ajgrf.com> writes:

> Great article, Pierre! I've known for a while how to do all this, but
> I still just used one big profile. Following along with your article,
> I finally went ahead and split it up.

While I was writing the blog and asking people around, I came to realize
this: it seems that most of the community doesn't use manifests or
multiple profiles so much :p  Which is a little ironic considering
"reproducible profiles" are the flagship of Guix! ;)

I hope that this article will help start a movement and get more users
on multiple profiles, which will help fixing the numerous multi-profile
issues that many packages suffer from:

- Emacs
- Aspell
- GST plugins

And probably many more...

> I noticed some typos though. This line has mismatched quotes:
>
>> export MANPATH=/path/to/profile${MANPATH:+:}$MANPATH"
>
> And this sentence is missing a couple words in the cookbook version:
>
>> This means that the exact same profile can be anytime, with

Will fix as soon as possible, thanks for reporting!

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Bengt Richter]

Hi Pierre,

On +2019-10-26 12:00:30 +0200, Pierre Neidhardt wrote:
> "Thompson, David" <dthompson2@worcester.edu> writes:
> 
> > Great article!
> 
> Thanks! :)
> 
> > I spotted a typo in the first paragraph: "on a same system" should be
> > "on the same system."
> 
> I can fix it.  Out of curiosity, why is it wrong?  "All users on a
> system..."  is correct, "All users on a given system" too, so I wonder
> why "on a same system" would not be.  What I meant here is "the same
> unspecified system".
> 
[...]

How would you say it in French? (I'm trying to recall high school French here, so be kind ;-)

I think english "a" is like French "un" or "une" -- so translating "on a same system" literally
(using my flawed French), does "en un même système" sound right to you?

It doesn't to me, unless même has a sense of pareil used that way.
Maybe "en utilisant le même système" ? (note le/the -- not un/a)
--
Regards,
Bengt Richter

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Bengt Richter <bokr@bokr.com> writes:

> How would you say it in French? (I'm trying to recall high school French here, so be kind ;-)
>
> I think english "a" is like French "un" or "une" -- so translating "on a same system" literally
> (using my flawed French), does "en un même système" sound right to you?
>
> It doesn't to me, unless même has a sense of pareil used that way.
> Maybe "en utilisant le même système" ? (note le/the -- not un/a)

Yes, in French "sur un même système" is correct ;)

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Pjotr Prins]

On Sat, Oct 26, 2019 at 12:02:51PM +0200, Pierre Neidhardt wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > On Fri, Oct 25, 2019 at 12:36:01PM -0400, Thompson, David wrote:
> >> On Fri, Oct 25, 2019 at 6:57 AM Ludovic Courtès <ludo@gnu.org> wrote:
> >> >
> >> > Hello Guix!
> >> >
> >> > Here’s a new blog post by Pierre Neidhardt entitled “Guix Profiles in
> >> > Practice”:
> >> >
> >> >   https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
> >> >
> >> > A great discussion on the benefits of manifests and on ways to manage
> >> > several profiles!
> >> 
> >> Great article!
> >
> > I agree. One useful thing not mentioned in there is, that before
> > loading a profile, it may be worthwhile to empty the shell with
> >
> >   env -i /bin/bash --login --noprofile --norc
> >
> >   . ~/opt/my-tools-profile/etc/profile
> >
> > so no existing shell variables may pollute your beautiful setup. 
> 
> Nice tip, Pjotr!
> 
> We can add it to the cookbook.  Shall I add it to the blog article now
> that it's published?

Why not?

> In https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00565.html
> we discussed the possibility to remove a specific profile from the
> environment, which would be a more general version of what you propose.
> It currently has some shortcomings, but maybe we can fix them.

Sounds great.

Pierre, we have the minimalistic and emerging languages devroom at
FOSDEM this year. I am thinking we could do a talk about using Guix as
a development environment. I mean profiles are great for development -
I use them all the time, including guix environment -C. That could be
a talk.

Another talk could be about programming Guix from the REPL. Guix as a
DSL if you will. Anyone interested in doing a talk about that?

BTW I am also starting to use rash - the racket shell and we have
gash. Anyone want to talk about that? We should invite the authors.

Pj

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Pjotr Prins <pjotr.public12@thebird.nl> writes:

>> We can add it to the cookbook.  Shall I add it to the blog article now
>> that it's published?
>
> Why not?

Depends how we look at the "Guix blog": shall we guarantee the content
of the articles to remain the same (beside typos) or shall we update
them as new ideas and other changes pop up?

The latter option has higher maintenance costs, plus we would need a way
to tell the reader when the article was first created, last edited, and
a link to the history of changes.

For the cookbook we've got all that with Git.

> Pierre, we have the minimalistic and emerging languages devroom at
> FOSDEM this year. I am thinking we could do a talk about using Guix as
> a development environment. I mean profiles are great for development -
> I use them all the time, including guix environment -C. That could be
> a talk.

You offering me to give a talk on this?  Why not, we can talk about it :)


> Another talk could be about programming Guix from the REPL. Guix as a
> DSL if you will. Anyone interested in doing a talk about that?

I would be very interested if someone could explain how they hack with
Geiser: I'm still frustrated with it on a daily basis :p I'm in
particular interested in debugging.  Regarding Guix-specific debugging,
I wonder how Guix developers debug staged code (i.e. when errors happen
for code executed by the daemon).

> BTW I am also starting to use rash - the racket shell and we have
> gash. Anyone want to talk about that? We should invite the authors.

Just watched the video: https://rash-lang.org/
It's amazing!
Now all we need is an Emacs (or https://github.com/soegaard/remacs?) integration...

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Hartmut Goebel]

Am 27.10.19 um 12:30 schrieb Pierre Neidhardt:
> Depends how we look at the "Guix blog": shall we guarantee the content
> of the articles to remain the same (

No. This will become a maintenance burden. The article already says
there is an update version in the cookbook. IMHO this is okay.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: “Guix Profiles in Practice”

[Konrad Hinsen]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> "Thompson, David" <dthompson2@worcester.edu> writes:
>
>> if it's a good idea.  Probably not.  So, I wonder if maybe a new
>> subcommand, say 'guix develop', could address this common development
>> use-case while allowing 'guix environment' to continue being the swiss
>> army knife that it is.  Some simple naming conventions could make this
...

> This is essentially what you propose, but to have it at the CLI level
> would provide several benefits:
...

> Both issues could be addressed the same way.

Perhaps. But then, "could" doesn't imply "should". I'd love to see all
that functionality easily accessible from the CLI, but I can't say I
know how this should best be organized.

Maybe we should start a Guix CLI nursery. A project/repository separate
from Guix itself that contains a copy of the "guix" script under a
different name ("guixx" for guix-extras?) and with the same interface
for scripting modules. We could then use this to play collectively with
ideas, and if something turns out to work well, migrate it to the
official Guix CLI.

Does this sound like a good idea? Would anyone else participate in such
an experiment?

Cheers,
  Konrad.

Re: “Guix Profiles in Practice”

[Jelle Licht]

Konrad Hinsen <konrad.hinsen@fastmail.net> writes:

> Maybe we should start a Guix CLI nursery. A project/repository separate
> from Guix itself that contains a copy of the "guix" script under a
> different name ("guixx" for guix-extras?) and with the same interface
> for scripting modules. We could then use this to play collectively with
> ideas, and if something turns out to work well, migrate it to the
> official Guix CLI.
>
> Does this sound like a good idea? Would anyone else participate in such
> an experiment?

This could even work as a proper guix channel, once
http://issues.guix.info/issue/37399 is fixed!

Re: “Guix Profiles in Practice”

[Konrad Hinsen]

On 27/10/2019 12:30, Pierre Neidhardt wrote:
>> Another talk could be about programming Guix from the REPL. Guix as a
>> DSL if you will. Anyone interested in doing a talk about that?
> I would be very interested if someone could explain how they hack with
> Geiser: I'm still frustrated with it on a daily basis :p I'm in
> particular interested in debugging.

I thought I was the only one having difficulties with Geiser and Guix. 
Plenty of Geiser features that work fine with small programs seem to 
fail with Guix, perhaps because of the sheer size of the codebase. 
Jumping to symbol definitions, for example, or access to documentation.

Konrad.

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

> Jumping to symbol definitions, for example, or access to documentation.

I can jump to definition with no problem.  Is your load path set
properly?

Access to the manual has been broken forever apparently.

Work-around here: https://gitlab.com/jaor/geiser/issues/252


Some of the things that frustrate me most:

- Debug-stepping does not seem to work.
- Re-compiling big .scm files (e.g. emacs-xyz.scm) takes really long.
  Is there a way to skip the lengthy compilation and hack from the REPL?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Konrad Hinsen]

Hi Pierre,

>> Jumping to symbol definitions, for example, or access to documentation.
>
> I can jump to definition with no problem.  Is your load path set
> properly?

After inspection... no. At least not in all my Guix installations.
It does work fine with the right path.

> Access to the manual has been broken forever apparently.
>
> Work-around here: https://gitlab.com/jaor/geiser/issues/252

Great, thanks! The biggest improvement in my Guix experience for a
while!

Cheers,
  Konrad.

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Pjotr, I've added your tip to the cookbook.

>   env -i /bin/bash --login --noprofile --norc
>
>   . ~/opt/my-tools-profile/etc/profile

Note that I've replaced /bin/bash with $(which bash) since /bin/bash
does not exist on Guix System ;)

Thanks for sharing!

Cheers!

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Tanguy Le Carrour]

Hi Pierre, Hi Guix!

Thanks for your article! It's been really useful!

I have two rather simple questions:
#1. why put the profile in `"$GUIX_EXTRA_PROFILES"/my-project/my-project`
    instead of `"$GUIX_EXTRA_PROFILES"/my-project`? I tried to create 2
    profiles right under `"$GUIX_EXTRA_PROFILES"`, and it seems to work!
#2. how can I remove a profile?! … actually, I figured out that removing
    the links works. Garbage would be (magically) collected on the next
    `guix gc` ("removing stale link from…").

Is point #2 the reason why the profiles are stored in subfolders?! If
yes, I would use `"$GUIX_EXTRA_PROFILES"/my-project/current` instead.
Does it make sense?!
Does point #2 deserve a mention in the cookbook?

My actual concern with profiles comes from the fact that I'm a Fish [1]
user. So I cannot "just" source the profile. Work-arounds exist [2],
but I don't quite like them. The good thing is I'm also a direnv [3] user
and this solves the problem it a neat way!
I'm working on a direnv function (`use profile my-project`) that would activate
the profile whenever I `cd` to a project folder.
I will eventually submit it upstream, but first, I have to figure out a way
to keep fish and direnv available when I activate a profile, because PATH
is overwritten and those packages are not in my profile! :-(

[1]: https://fishshell.com
[2]: https://github.com/edc/bass
[3]: https://direnv.net

This brings me to my last (but not quite related) question… where does
`--search-paths` get its information from? I guess it's something in the
package definition that tells it "you have to export PYTHONPATH", but
I'm not sure where. Any clue welcome!

Anyway, thanks again for your work on the article!

-- 
Tanguy

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Hi Tanguy,

Glad you like it!

Tanguy Le Carrour <tanguy@bioneland.org> writes:

> I have two rather simple questions:
> #1. why put the profile in `"$GUIX_EXTRA_PROFILES"/my-project/my-project`
>     instead of `"$GUIX_EXTRA_PROFILES"/my-project`? I tried to create 2
>     profiles right under `"$GUIX_EXTRA_PROFILES"`, and it seems to work!

Maybe this wasn't completely clear in the article.  The reason is that
successive generations create symlinks next to "my-project.  In the end,
the file hierarchy will look like this:

$GUIX_EXTRA_PROFILES/my-project/my-project
$GUIX_EXTRA_PROFILES/my-project/my-project-1
$GUIX_EXTRA_PROFILES/my-project/my-project-2
$GUIX_EXTRA_PROFILES/my-project/my-project-3
...

If you have multiple profiles, having a subdir for
each profile makes your life easier.

> #2. how can I remove a profile?! … actually, I figured out that removing
>     the links works. Garbage would be (magically) collected on the next
>     `guix gc` ("removing stale link from…").

Indeed! ;)

> Is point #2 the reason why the profiles are stored in subfolders?! If
> yes, I would use `"$GUIX_EXTRA_PROFILES"/my-project/current` instead.
> Does it make sense?!

You can use current, the name is arbitrary.

> My actual concern with profiles comes from the fact that I'm a Fish [1]
> user.

This is a known problem and it's being discussed here:
https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00565.html

Your insights are welcome! ;)

> This brings me to my last (but not quite related) question… where does
> `--search-paths` get its information from? I guess it's something in the
> package definition that tells it "you have to export PYTHONPATH", but
> I'm not sure where. Any clue welcome!

Look at the `native-search-path` field in the package definitions.

> Anyway, thanks again for your work on the article!

You're welcome!

Cheers!

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Ludovic Courtès]

Hi,

"Thompson, David" <dthompson2@worcester.edu> skribis:

> 'guix environment' is a very composable command, and it's not clear to
> me how I would add the stuff I want onto it and it's even less clear
> if it's a good idea.  Probably not.  So, I wonder if maybe a new
> subcommand, say 'guix develop', could address this common development
> use-case while allowing 'guix environment' to continue being the swiss
> army knife that it is.  Some simple naming conventions could make this
> tool "just work."  Running 'guix develop' would check for a profile
> symlink with some canonical name, for example '.guix-develop-profile'.
> If it exists, it applies the environment variables and spawns a
> subshell.  If it doesn't exist, it looks for a 'develop.scm' file
> (canonical name TBD), builds the profile, symlinks it to
> '.guix-develop-profile', and then does the prior steps.  The tool
> would provide a mechanism to update, etc. and it could even be
> expanded later to spawn services like databases.

That sounds like a good idea.  ‘guix develop’ could keep the profiles it
manages under ~/.cache/guix.

Now, this would be very much stateful: you can’t tell in advance whether
you’re going to build a new profile based on the current Guix, or
whether you’re going to reuse a previously cached profile that could be
arbitrarily old.  That doesn’t sound great.

Perhaps we should focus on improving the performance of ‘guix
environment’ first and foremost?

Thanks,
Ludo’.

Re: “Guix Profiles in Practice”

[Jonathan Frederickson]

On Nov 3, 2019, at 9:24 AM, Ludovic Courtès <ludo@gnu.org> wrote
> Now, this would be very much stateful: you can’t tell in advance whether
> you’re going to build a new profile based on the current Guix, or
> whether you’re going to reuse a previously cached profile that could be
> arbitrarily old.  That doesn’t sound great.

What if something identifying the profile (directory name? config file?) included info about the Guix revision it was built from? That way a profile would be reused if it’s built from the same Guix revision, but if you switch revisions it’d be rebuilt.

I’m not sure how this would interact with a profile built from packages in multiple channels.

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Ludovic Courtès <ludo@gnu.org> writes:

> That sounds like a good idea.  ‘guix develop’ could keep the profiles it
> manages under ~/.cache/guix.
>
> Now, this would be very much stateful: you can’t tell in advance whether
> you’re going to build a new profile based on the current Guix, or
> whether you’re going to reuse a previously cached profile that could be
> arbitrarily old.  That doesn’t sound great.

This could be fixed, maybe the following way:

- Dump the channel specifications for every profile in
  etc/channel-spec.scm for instance.

- Merge Konrad's time-machine script so that we can easily reuse a
  channel specification to activate a profile.

> Perhaps we should focus on improving the performance of ‘guix
> environment’ first and foremost?

But isn't it orthogonal to this issue?

As I understand it, the current discussion is about "pinning"
profiles.
Should any dependency get garbage collected, an environment will need
Internet access to refetch the missing parts; I think this is what we
are trying to avoid, regardless of how fast `guix environment` is.


What about `guix environment --pin` instead of `guix develop`?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Jonathan Frederickson <jonathan@terracrypt.net> writes:

> What if something identifying the profile (directory name? config
> file?) included info about the Guix revision it was built from? That
> way a profile would be reused if it’s built from the same Guix
> revision, but if you switch revisions it’d be rebuilt.
>
> I’m not sure how this would interact with a profile built from packages in multiple channels.

Absolutely, I was suggesting something similar in another thread: dump
the output of `guix describe -f channels` into the profile,
e.g. etc/channel-spec.scm.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Ludovic Courtès]

Hello,

Jonathan Frederickson <jonathan@terracrypt.net> skribis:

> On Nov 3, 2019, at 9:24 AM, Ludovic Courtès <ludo@gnu.org> wrote
>> Now, this would be very much stateful: you can’t tell in advance whether
>> you’re going to build a new profile based on the current Guix, or
>> whether you’re going to reuse a previously cached profile that could be
>> arbitrarily old.  That doesn’t sound great.
>
> What if something identifying the profile (directory name? config file?) included info about the Guix revision it was built from? That way a profile would be reused if it’s built from the same Guix revision, but if you switch revisions it’d be rebuilt.

Then in that case you’re just looking for a form of caching, is that
correct?

If ‘guix environment’ were 10 times faster, it’d be just fine, right?

(It’s not getting 10 times faster any time soon I’m afraid :-), but just
to make sure I understand whether we’re talking about a UI issue or a
performance issue.)

Thanks,
Ludo’.

Re: “Guix Profiles in Practice”

[Carlo Zancanaro]

Hey Pierre,

On Mon, Nov 04 2019, Pierre Neidhardt wrote:
> As I understand it, the current discussion is about "pinning"
> profiles.
> Should any dependency get garbage collected, an environment will 
> need
> Internet access to refetch the missing parts; I think this is 
> what we
> are trying to avoid, regardless of how fast `guix environment` 
> is.
>
> What about `guix environment --pin` instead of `guix develop`?

Have you used `guix environment --root`?

In my git checkout of the Guix repository I once ran `guix 
environment guix --root=.environment`, and now whenever I want to 
hack on Guix I start a shell and `source 
.environment/etc/profile`. The .environment symlink is treated as 
a GC root by Guix, and because I'm not actually invoking Guix 
there's never a risk that it will attempt to fetch anything from 
the internet.

Upgrading the environment is quite easy, and must be done 
manually: I delete the existing symlink and run `guix environment 
guix --root=.environment` again. If I'm feeling paranoid I'll run 
`guix environment guix` once first to make sure it succeeds, 
before deleting the old symlink and adding the 
`--root=.environment` to the end.

Carlo

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Oh my!!  I had no clue about `guix environment --root` :/
That's embarrassing... :p

This probably solves many issues.

I guess we ought to update the cookbook with this!

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: “Guix Profiles in Practice”

[Ludovic Courtès]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Oh my!!  I had no clue about `guix environment --root` :/
> That's embarrassing... :p

At least we learned something about discoverability of these options.
:-)

> This probably solves many issues.
>
> I guess we ought to update the cookbook with this!

That’d be great!

Ludo’.

Re: “Guix Profiles in Practice”

[Pierre Neidhardt]

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

Ludovic Courtès <ludo@gnu.org> writes:

> Pierre Neidhardt <mail@ambrevar.xyz> skribis:
>
>> Oh my!!  I had no clue about `guix environment --root` :/
>> That's embarrassing... :p
>
> At least we learned something about discoverability of these options.
> :-)
>
>> This probably solves many issues.
>>
>> I guess we ought to update the cookbook with this!
>
> That’d be great!

Hmm, actually I don't really know where to put it.

The trick is that `guix environment --root` does no just use the
symlinked profile when it exists, it first builds the environment and
thus builds/downloads packages if necessary.

We don't  talk about guix environment in the cookbook chapter, so I'm
not sure if it's a good idea to introduce it there.

Maybe we first need to progress with regard to the command line
enhancements we are discussing in the other thread.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]