5 ms·

How would one use a modern IDE in this environment especially when you have multiple projects with different dependencies open at the same time? Would one need

by ivanb 3y ago

How would one use a modern IDE in this environment especially when you have multiple projects with different dependencies open at the same time? Would one need to install the IDE as a dependency of a project? Would all the IDEs have different settings?

dannymi 3y ago
That depends on what you want to containerize (which I assume you are after? If you don't containerize it works just like any other distro--it will be transparent to the IDE (because the IDE doesn't care that suddendly your gcc in PATH is in $HOME/.guix-profile/bin, or that pkg-config picks up packages in PKG_CONFIG_PATH which happen to be in /gnu/store/3248235325322332w-wrwqewewtew-libpng/lib/pkgconfig)). Personally, I containerize the weird build tools I can't fully trust (vendor toolchains etc) and have wrapper scripts (written in bash) in PATH. The IDE is none the wiser that those are containerized. It's possible to have multiple packages in a permanent custom profile, if that's what you mean (that's kinda the manifest stuff at the end of the article). Those can be started all in the same container. For example, yes, you can have a profile which contains java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain for your specific project. This does not change your specific project's package. If you are asking whether java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain would be referred to in your guix.scm, I wouldn't do that. But in your profile? yes. >Would one need to install the IDE as a dependency of a project? Why that? The IDE, like a text editor, is a developer tool and doesn't end up with the project artifacts that you are building. So it's not any kind of dependency of the project. For example when you build Java projects using Eclipse, your projects are actually built using gradle and then openjdk. So gradle is a native-input, openjdk is a build system input and Eclipse is NO dependency of your project's guix package. Your developer profile, however, can contain multiple packages (in the container). That's not what's built when you build just the package using "guix build -f guix.scm", though (those builds are isolated). Think of a profile as something like as set of packages and also environment variables that you can refer to as a whole (containerize etc) using a new fixed name. Or think of companies where you have different hats on. Depending on the hat, you would have a profile--so the developer hat doesn't actually have the tools to delete production :) Most other distributions have just one global profile, not even per user. In guix, you have a default profile ".guix-profile" per user, and you can make any number of extra ones (no sudo needed). >when you have multiple projects with different dependencies open at the same time? Hmm, I think I can see what you are getting at. I don't know whether there are IDE plugins that are guix-aware. Would be easy to do though (it would just use a custom build step as the only build step - "guix build -f guix.scm" . This automatically makes a container with your package, its build system and your package's dependencies in it and builds that (if dependency is not built yet, makes a container with that package and its dependencies in it and builds that, and so on, recursively). The IDE would then pick up the output of "guix build" which is the path to the result (somewhere in /gnu/store/...)). The path names used inside and outside the container are the same, and the dependencies are kept around for a while, so the IDE will have a good time referring to those for headers etc when debugging or doing autocomplete.
- dannymi 3y ago
  Somewhat un-guixy-but-easy way to get started in: $ mkdir -p ~/profiles $ guix package -p ~/profiles/developer -i gcc-toolchain gfortran-toolchain emacs $ guix shell -p ~/profiles/developer --check (env)$ cd yourproject # which has guix.scm inside (env)$ emacs (have emacs do "guix build -f guix.scm" in there from time to time) This creates a new profile "developer" (you might want that to be more granular eventually, but whatever) with the 3 packages inside and then starts a shell inside that profile. You will have access to those inside that shell (only guarded by PATH etc), but you will ALSO have access to all the tools-outside-that-shell. If you want to containerize, you can do that, too. Note that then you won't have any of the usual packages, including coreutils, available (no "ls" :) ): (env)$ exit $ guix shell -C -p ~/profiles/developer --check (env)$ ls sh: ls: command not found (env)$ exit $ guix package -p ~/profiles/developer -i coreutils $ guix shell -C -p ~/profiles/developer --check (env)$ ls It works! (env)$ guix sh: guix: command not found Well, that can't be good. (env)$ exit $ guix package -p ~/profiles/developer -i guix $ guix shell -C -p ~/profiles/developer --check (env)$ guix build -f guix.scm It works! Note that the "-C" automatically also exposes the current directory that "guix shell" saw when starting up to the container.
  - dannymi 3y ago
    The manifest stuff is so you can have a more declarative way to specify packages (think Cargo.toml instead of mutable Debian installation). (env)$ exit $ guix package --export-manifest -p ~/profiles/developer (specifications->manifest (list "guix" "coreutils" "emacs" "gfortran-toolchain" "gcc-toolchain")) $ guix package --export-manifest -p ~/profiles/developer > yourproject/manifest.scm $ guix shell -C -m yourproject/manifest.scm (env)$ Works the same as before. Now more declarative. And you can throw away ~/profiles/developer* now, it will be rebuilt each time (with caching, don't worry).
- ivanb 3y ago
  The whole thing is enticing. I'm looking at it as a replacement for tool version managers like NVM, pyenv, asdf and probably as a replacement for local Docker. There is, however, a doubt that I might fight it more than I would benefit from it. After all, the IDEs were not designed to work in Guix environment. There is no way to tell without trying, I guess.
mekeor 3y ago
You may use direnv which supports many IDEs, e.g. VSCode and Emacs. Here's a tutorial for Emacs: https://rednosehacker.com/combo-guix-shell-emacs-envrc-el https://rednosehacker.com/combo-guix-shell-emacs-envrc-el
davexunit 3y ago
I use Emacs installed for my user account (so not as a dependency of any project), and install an integration that works with 'guix shell' for per-project software configurations. Emacs' project.el extension allows me to switch between many projects easily.
- Kalq 3y ago
  Curious what integration you're using? I'm using direnv with envrc but I'm interested to see of any good alternatives.
  - davexunit 3y ago
    I use buffer-env. Some things that I don't love about it but it does the job and it understands guix.scm/manifest.scm files natively so I don't have to put them in an .envrc file or anything.
ParetoOptimal 3y ago
In Nix each project gets it's PATH updated to project specific absolute paths in the Nix store. This is automated with direnv and an extension for direnv in your ide so this transparently happens when you open that project. tl;dr Ide plugin to use same PATH and stuff as nix develop

by ivanb 3y ago

dannymi 3y ago

That depends on what you want to containerize (which I assume you are after? If you don't containerize it works just like any other distro--it will be transparent to the IDE (because the IDE doesn't care that suddendly your gcc in PATH is in $HOME/.guix-profile/bin, or that pkg-config picks up packages in PKG_CONFIG_PATH which happen to be in /gnu/store/3248235325322332w-wrwqewewtew-libpng/lib/pkgconfig)). Personally, I containerize the weird build tools I can't fully trust (vendor toolchains etc) and have wrapper scripts (written in bash) in PATH. The IDE is none the wiser that those are containerized. It's possible to have multiple packages in a permanent custom profile, if that's what you mean (that's kinda the manifest stuff at the end of the article). Those can be started all in the same container. For example, yes, you can have a profile which contains java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain for your specific project. This does not change your specific project's package. If you are asking whether java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain would be referred to in your guix.scm, I wouldn't do that. But in your profile? yes. >Would one need to install the IDE as a dependency of a project? Why that? The IDE, like a text editor, is a developer tool and doesn't end up with the project artifacts that you are building. So it's not any kind of dependency of the project. For example when you build Java projects using Eclipse, your projects are actually built using gradle and then openjdk. So gradle is a native-input, openjdk is a build system input and Eclipse is NO dependency of your project's guix package. Your developer profile, however, can contain multiple packages (in the container). That's not what's built when you build just the package using "guix build -f guix.scm", though (those builds are isolated). Think of a profile as something like as set of packages and also environment variables that you can refer to as a whole (containerize etc) using a new fixed name. Or think of companies where you have different hats on. Depending on the hat, you would have a profile--so the developer hat doesn't actually have the tools to delete production :) Most other distributions have just one global profile, not even per user. In guix, you have a default profile ".guix-profile" per user, and you can make any number of extra ones (no sudo needed). >when you have multiple projects with different dependencies open at the same time? Hmm, I think I can see what you are getting at. I don't know whether there are IDE plugins that are guix-aware. Would be easy to do though (it would just use a custom build step as the only build step - "guix build -f guix.scm" . This automatically makes a container with your package, its build system and your package's dependencies in it and builds that (if dependency is not built yet, makes a container with that package and its dependencies in it and builds that, and so on, recursively). The IDE would then pick up the output of "guix build" which is the path to the result (somewhere in /gnu/store/...)). The path names used inside and outside the container are the same, and the dependencies are kept around for a while, so the IDE will have a good time referring to those for headers etc when debugging or doing autocomplete.

dannymi 3y ago
Somewhat un-guixy-but-easy way to get started in: $ mkdir -p ~/profiles $ guix package -p ~/profiles/developer -i gcc-toolchain gfortran-toolchain emacs $ guix shell -p ~/profiles/developer --check (env)$ cd yourproject # which has guix.scm inside (env)$ emacs (have emacs do "guix build -f guix.scm" in there from time to time) This creates a new profile "developer" (you might want that to be more granular eventually, but whatever) with the 3 packages inside and then starts a shell inside that profile. You will have access to those inside that shell (only guarded by PATH etc), but you will ALSO have access to all the tools-outside-that-shell. If you want to containerize, you can do that, too. Note that then you won't have any of the usual packages, including coreutils, available (no "ls" :) ): (env)$ exit $ guix shell -C -p ~/profiles/developer --check (env)$ ls sh: ls: command not found (env)$ exit $ guix package -p ~/profiles/developer -i coreutils $ guix shell -C -p ~/profiles/developer --check (env)$ ls It works! (env)$ guix sh: guix: command not found Well, that can't be good. (env)$ exit $ guix package -p ~/profiles/developer -i guix $ guix shell -C -p ~/profiles/developer --check (env)$ guix build -f guix.scm It works! Note that the "-C" automatically also exposes the current directory that "guix shell" saw when starting up to the container.
- dannymi 3y ago
  The manifest stuff is so you can have a more declarative way to specify packages (think Cargo.toml instead of mutable Debian installation). (env)$ exit $ guix package --export-manifest -p ~/profiles/developer (specifications->manifest (list "guix" "coreutils" "emacs" "gfortran-toolchain" "gcc-toolchain")) $ guix package --export-manifest -p ~/profiles/developer > yourproject/manifest.scm $ guix shell -C -m yourproject/manifest.scm (env)$ Works the same as before. Now more declarative. And you can throw away ~/profiles/developer* now, it will be rebuilt each time (with caching, don't worry).
ivanb 3y ago
The whole thing is enticing. I'm looking at it as a replacement for tool version managers like NVM, pyenv, asdf and probably as a replacement for local Docker. There is, however, a doubt that I might fight it more than I would benefit from it. After all, the IDEs were not designed to work in Guix environment. There is no way to tell without trying, I guess.

mekeor 3y ago

You may use direnv which supports many IDEs, e.g. VSCode and Emacs. Here's a tutorial for Emacs: https://rednosehacker.com/combo-guix-shell-emacs-envrc-el https://rednosehacker.com/combo-guix-shell-emacs-envrc-el

davexunit 3y ago

I use Emacs installed for my user account (so not as a dependency of any project), and install an integration that works with 'guix shell' for per-project software configurations. Emacs' project.el extension allows me to switch between many projects easily.

Kalq 3y ago
Curious what integration you're using? I'm using direnv with envrc but I'm interested to see of any good alternatives.
- davexunit 3y ago
  I use buffer-env. Some things that I don't love about it but it does the job and it understands guix.scm/manifest.scm files natively so I don't have to put them in an .envrc file or anything.

ParetoOptimal 3y ago

In Nix each project gets it's PATH updated to project specific absolute paths in the Nix store. This is automated with direnv and an extension for direnv in your ide so this transparently happens when you open that project. tl;dr Ide plugin to use same PATH and stuff as nix develop