Hi Simon,
Quoting zimoun (2022-10-24 09:34:09) > On dim., 23 oct. 2022 at 17:40, Tanguy LE CARROUR <tan...@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