nonguix VS asdf

I use the nonguix channel for non-free stuff https://gitlab.com/nonguix/nonguix. It has the mainline linux kernel (instead of the free linux-libre), proprietary drivers and a bunch of other proprietary stuff.

Guix has these things called "channels" containing package definitions. They're actually just git repositories. nonguix was made to have nonfree stuff. It has a lot of stuff including the mainline linux kernel.

https://gitlab.com/nonguix/nonguix you can use non free software if you need to. But the project itself is a gnu project and as such should not encourage users to use non free software.

I think Guix approach is good, community helps with open-source packages, some third-party manages the non-free channels. And they are as easy to use

https://gitlab.com/nonguix/nonguix

There are flatpacks, snaps, appimages, PPAs, channels... why would you except a linux distro maintainer to work for free for a billion dollar company? Testing and maintain their software

My background consists of using/developing Guix, openSUSE/SUSE as well of OBS. I'm a co-maintainer at nonguix, where we provide non-free software which is not allowed at upstream Guix. We even run our own little build service, called Cuirass. This softwore is developed mostly by https://www.reddit.com/user/mothacehe/ :)

$ guix describe Generation 22 May 15 2022 19:02:44 (current) guix 9860c90 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9860c90e8e5362e0e843efbd45f4563b9746a196 guix-gaming-games 9924ad0 repository URL: https://gitlab.com/guix-gaming-channels/games.git branch: master commit: 9924ad0a66f98ea1b538761fd49521acf4f689a3 flat 094746c repository URL: https://github.com/flatwhatson/guix-channel.git branch: master commit: 094746c1e2e90f2df1e598ab1fd0abb4d75ce84d nonguix 1de0c32 repository URL: https://gitlab.com/nonguix/nonguix branch: master commit: 1de0c32142c54bc73af5556d5e45c77152b31f0f

Thanks for the link. Although I was just planning to follow the steps in the https://gitlab.com/nonguix/nonguix repo.

You'll want to read about "channels" which are additional software repositories you can include in Guix from anywhere, There are other channels, but the main one for non-free is https://gitlab.com/nonguix/nonguix

Even GNU Guix System (which is a fully libre, FSF approved distro) can be used to install non-free packages. All you have to do is add the nonguix repository.

The main issue most people have with asdf is that it’s annoyingly slow. Not unusably so, but just enough that it’s irritating.

I identified [0] the source for much of it (sub-shells and pipes) and began a PR [1], but became bogged down with BATS testing, and then found mise / rtx, so kind of lost interest. Sorry. You can always implement these if you’d like.

[0]: https://github.com/asdf-vm/asdf/issues/290#issuecomment-1383...

[1]: https://github.com/asdf-vm/asdf/pull/1441

Or if you need to manage more than just node, asdf has been around for over a decade and works great. You can use a .tool-versions to change runtimes for each project you have, in addition to managing your global runtime versions

https://asdf-vm.com/

Why not just use a tool like asdf (https://asdf-vm.com/) or mise (https://mise.jdx.dev/)?

These tools have the advantage of not being multi-taskers and can manage version for all your tools. You wouldn’t need pyenv and npm and rvm and…

We’ve even started committing the .mise.toml files for projects to our repos. That way, since we work on multiple projects that may need multiple versions of the same tool, it’s handled and documented.

The purpose of a version manager is to help you navigate or install any tools for development easily. Version Manager can be one tool for each dependency (e.g. NVM, g) or One tool for all dependencies (e.g. asdf, mise).

(asdf)[https://asdf-vm.com/] fully supports Python and almost any other language. I've been using it for Ruby, Python, Elixir, and other languages for years and never looked back.

Secondly, our development environments must not drift, because then code may behave differently and a change could pass on our machine but fail in production. There are many tools for locking down environments, e.g nix, pkgx, asdf, containers, etc., and they all share the common goal of being able to lock down dependencies for an environment accurately and deterministically. And that needs to be enforced in our local workflow so we don't have to rely on CI environments for correctness. All developers must have environments that are effectively identical to what runs in CI (which itself should be representative of the production environment).

There are many ways this can be done (e.g nix, pkgx, asdf, containers, etc.), and we won’t get into which specific tools to use, because we'll instead cover the essential essence of preventing environment drift: