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 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 and 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's manifest? 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.

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.

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).

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.

It depends on your use case.

For example, .NET core is nonexistent in Guix and nobody in the community seems to have any use for it. Also, there's an upstream bug report in dotnet core stating that it doesn't have functioning bootstrapping (AT ALL), and Microsoft doesn't care.

Java bootstrapping in Guix actually works pretty well, but only up to (and somewhat excluding) Maven. Everything higher than that is extremely difficult to build without cheating.

So I'd say if you use C, C++, Rust, Scheme, Haskell, R, Python, Ruby, Perl or stuff like that, Guix is awesome.

For Java with Ant, it's ok.

For Java EE, it's doable but convoluted (just install binary IntelliJ community edition from IntelliJ's website, for example). I'm using that myself, on Guix, and it's ok.

For .NET, ha ha, better be prepared to use mono from Xamarin. Realistically, .NET is not working. .NET IDEs? Nope.

>After all, the IDEs were not designed to work in Guix environment

It depends on how much they need to be designed for that. It works very well for IntelliJ, and I don't think that IntelliJ can tell at all that it's inside a guix profile.

What is true is that IDEs could make more use of the EXTRA power that guix gives (like guix build --with-source and guix build --with-patches in order to automatically patch dependencies for quick tests), and it's totally annoying that they don't.

Note that Docker is also available in Guix, both the actual daemon (not that guix uses it...) and as a guix build output target.

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

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.

Curious what integration you're using? I'm using direnv with envrc but I'm interested to see of any good alternatives.

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.

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