4 ms·

What's also good is that one can combine cargo with Guix as an OS/multi-language package manager, for example when other tools or C libraries (say, alsa-lib) ar

by jnxx 6y ago

What's also good is that one can combine cargo with Guix as an OS/multi-language package manager, for example when other tools or C libraries (say, alsa-lib) are needed. Guix provides currently 15,000 packages including many rust packages (https://guix.gnu.org/packages/R/page/21/ https://guix.gnu.org/packages/R/page/21/ ), and uses of course cargo for building rust packages. The reason why I think this is the right way to do it is because in big , quickly-moving projects, the only comfortable way out of dependency hell is to use a Linux distribution with checked-to-work dependencies, or one is damned to the task of building a distribution oneself, and a checked distribution of packages is precisely what Guix provides. Because own, or project-specific package recipes, which contain dependency and build instructions, can just be added to the public package definitions (https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix/ https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix...), this allows to deterministically and hermetically build multi-language projects on top of a very solid base. And for testing with another version of a C dependency (say, alsa-lib 1.1.9), one just needs a branch with another version number in the build recipe.

choeger 6y ago
That sounds about fantastic. Is there a non-root way to build and a way to install at least some of the packages in my $HOME? Because as a developer I need to work with different branches. edit: How does it handle python wheels and other non-source language-specific packages?
- jnxx 6y ago
  > Is there a non-root way to build and a way to install at least some of the packages in my $HOME Yes. You can install Guix as a package manager on top of your POSIX OS. Then, you have profiles, and you can install packages into your personal profile in your $HOME, or into temporary project-specific environments. You can also define the environment by writing a manifest file which list requested packages and their versions, and put that file under version control. How it is used is documented here: https://guix.gnu.org/manual/en/guix.html#Package-Management https://guix.gnu.org/manual/en/guix.html#Package-Management > How does it handle python wheels and other non-source language-specific packages? Of course you can install Python packages: https://guix.gnu.org/packages/P/page/12/ https://guix.gnu.org/packages/P/page/12/ If there are no pre-built packages for your machine architecture (say, you are developing on ARM), they are built and installed on your machine (or, a build server which you defined), otherwise you get automatically a compiled package from the Guix server. Also, and in difference to pip and so on, any needed C libraries will be installed as well, with the right versions. So, it is a bit like Conda, but it will also work if your project happens to mix, say, Python, C, C++ and Rust, and perhaps runs on mips or armhf. (My next side project will be a Game with a strategy engine in Rust, and a GUI written in Racket, just as an example). I have not yet tried it with Python, but I can confirm it works with Common Lisp libraries. Basically, you can get anything which is FLOSS, and if you need proprietary stuff you might be able it via a non-free package channel (similar to Debian).

by jnxx 6y ago

choeger 6y ago

That sounds about fantastic. Is there a non-root way to build and a way to install at least some of the packages in my $HOME? Because as a developer I need to work with different branches. edit: How does it handle python wheels and other non-source language-specific packages?

jnxx 6y ago
> Is there a non-root way to build and a way to install at least some of the packages in my $HOME Yes. You can install Guix as a package manager on top of your POSIX OS. Then, you have profiles, and you can install packages into your personal profile in your $HOME, or into temporary project-specific environments. You can also define the environment by writing a manifest file which list requested packages and their versions, and put that file under version control. How it is used is documented here: https://guix.gnu.org/manual/en/guix.html#Package-Management https://guix.gnu.org/manual/en/guix.html#Package-Management > How does it handle python wheels and other non-source language-specific packages? Of course you can install Python packages: https://guix.gnu.org/packages/P/page/12/ https://guix.gnu.org/packages/P/page/12/ If there are no pre-built packages for your machine architecture (say, you are developing on ARM), they are built and installed on your machine (or, a build server which you defined), otherwise you get automatically a compiled package from the Guix server. Also, and in difference to pip and so on, any needed C libraries will be installed as well, with the right versions. So, it is a bit like Conda, but it will also work if your project happens to mix, say, Python, C, C++ and Rust, and perhaps runs on mips or armhf. (My next side project will be a Game with a strategy engine in Rust, and a GUI written in Racket, just as an example). I have not yet tried it with Python, but I can confirm it works with Common Lisp libraries. Basically, you can get anything which is FLOSS, and if you need proprietary stuff you might be able it via a non-free package channel (similar to Debian).