Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Tanguy LE CARROUR <tanguy@bioneland.org>]

Hi Simon,


Quoting zimoun (2022-10-24 09:34:09)
> On dim., 23 oct. 2022 at 17:40, Tanguy LE CARROUR <tanguy@bioneland.org> wrote:
> 
> >>     guix package --export-manifest > /tmp/my-pkgs.scm
> >>     guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...
> >
> > I'm not using manifest (anymore). I used to, but for the time being, I'm using
> > `divenv` + `guix shell` and I'm quite happy with that setup.
> 
> Note that the first command above creates the manifest for you.
> Usually, it works well enough. :-)

I guess the "problem" is that I'm a "pipe person". I just don't like
having to create a temp’ file.
But I agree that your solution is more elegant.


> Well, ’direnv’ + ’guix shell’ but you have a manifest, no?  I mean how
> does ’guix shell’ know what to provide inside this new shell?

I used to have a `manifest.scm` file. I even used to (silly me!) commit it
into the repository along side the project's code.
I recently realized that it was easier to only have a git-ignored
`.envrc` file containing:

```
use guix-shell python python-wrapper python-jedi poetry […]
```

The other project's dependencies are (still) managed by Poetry, so the
list passed to Guix shell is quite short.

Not that `guix-shell` is a custom function, for Direnv `guix` function
still uses `guix environment`. But this would also work:

```
use guix --ad-hoc python python-wrapper python-jedi poetry […]
```

For some projects that are not dev project, I sometimes use a
`manifest.scm`. I guess it also depends on the Moon phase. In those rare
cases, my `.envrc` contains the following:

```
use guix-shell -m manifest.scm
```

Which can be abbreviated to `use guix-shell`, because it auto-magically
loads the `manifest.scm` or `guix.scm` file present inside the folder.

Regarding the `guix.scm` file, I recently decided to also move them out
of the code repository of the (personal) projects I needed to package
for Guix, because they don't actually belong with the code. They now live in
a dedicated repository that I added to my Guix channels.


> For what it is worth, I have used similar workflow but I have been bored
> to run “guix pull”, do some stuff unrelated to ’project’, then later be
> back on ’project’ and then have failures.  Instead, my workflow is
> splited into 2 ways depending on my phase of the Moon.  Either, I create
> a profile inside the project directory.  Either, I use channels.scm +
> manifest.scm and often run via ’guixify’ script (see below); e.g.,
> 
>     guixify foo # run foo using the Guix environment
>     guixify     # enter in the environment

Thanks for sharing! I used to have the same kind of setup, but…


> Maybe, ’direnv’ would do a better job.

I wrote a `profile` function for Direnv that was doing the job of
loading the environment.

```
use profile the-profile-for-my-project
```

I also had a `guix-all-profile` command that would executing the same command
on all my profiles. Basically looping over them to `--upgrade` or `--delete-generations`.

But I found it easier to use Guix shell.


> The good point is that channels.scm and manifest.scm are included in the Git
> tree of the project. And they can be re-used with ’guix pack -f docker -m
> manifest.scm’ to generate Docker pack that I can share with colleagues.

My colleagues use Debian. We agreed that I would not pollute the repo
with my Guix files if they would not commit their Debian support files. 😅

Regards,

-- 
Tanguy