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.
$ 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)
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
(env)$ guix
sh: guix: command not found
(env)$ exit
$ guix package -p ~/profiles/developer -i guix
$ guix shell -C -p ~/profiles/developer --check
(env)$ guix build -f guix.scm
Note that the "-C" automatically also exposes the current directory that "guix shell" saw when starting up to the container.
(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)$
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 (something like 20 different Java VM and JDK packages are in guix, so you can do everything Java can do).
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.
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