Earlier quoted context omitted.
I came here just for this
Weird, since it’s not really relevant.
It is, though? Just swap "standards" with "programs"
Ditch your version manager
21–30 of 155 posts
Re: Ditch your version manager
#22> Nix is a tool that takes a unique approach to package management and system configuration. Nix is the basis of an OS distro: NixOS. This article is just re-articulating the idea that {the/an} OS distro should be managing this stuff, and not some fledgling language-specific programs (that go behind its back, and do a half-baked job by not controlling the packages external to their language ghetto).
I think NixOS is great, but you don’t need to switch to NixOS to use Nix. You can also install Nix on other Linux distributions or even on macOS, and use Nix to manage individual tools and projects without using it to manage your entire system.
Re: Ditch your version manager
#23Managing dependencies is a big problem, and I feel like we've given up on solving it directly, and instead built workarounds. If we question our assumptions, the first question is: Why do we need multiple Ruby versions at all? Why isn't the latest version of Ruby sufficient? Well, obviously, Ruby's behavior has changed over time. But why isn't it backward-compatible? Why can't I just run Ruby 3.0 with a flag that tel…
This just adds burden to programming language and library authors. Sure I could almost certainly support Python 2.7 and Python I imagine variations of the above apply to nokogiri and some amount of Ruby core developers.
I basically stopped writing Python because of the 2 -> 3 transition: the cost of waiting for dependencies to be ready for Python 3 was high enough that it made sense just to switch languages for everything.
Python was saved, basically, by it becoming _the_ language for data science in the same time frame. But, this could have very well turned into a Perl 6-style fiasco.
Re: Ditch your version manager
#24Earlier quoted context omitted.
Nix is very unixy so it probably could be made to work on WSL, but not native windows. Yes, if all of your dependencies are written in a single language, you can use the language-specific version manager. TFA was pointing out a solution that work across different languages.
It would be very nice to have a cross language and cross platform package manager. Most single language package managers are cross platform, and many single platform managers are cross language.
It might be possible to port it to msys/mingw
Re: Ditch your version manager
#25Earlier quoted context omitted.
Nix is very unixy so it probably could be made to work on WSL, but not native windows. Yes, if all of your dependencies are written in a single language, you can use the language-specific version manager. TFA was pointing out a solution that work across different languages.
It would be very nice to have a cross language and cross platform package manager. Most single language package managers are cross platform, and many single platform managers are cross language.
Conda manages this pretty well and the community ran “conda-forge” channel works. It’s language, platform and architecture agnostic. It only supports distributing binaries which can be a benefit or downside when compared to Nix’s “build the world with caching” approach depending on your needs. Personally I find conda’s approach to be more pragmatic for working with unprivileged systems and how packages expect to be used. Though I do hop the Nix-store like model continues to grow in popularity as it’s much better than the classic posix install layout.
In conda, packages are installed into “environments” which are just folders like Python’s venv except language agnostic so you can install specific OpenSSL/Clang/GCC/libWhatever versions and have one environment per project you work on. It’s also the only package manager I’m aware of that can provide a good experience across Windows/Linux/macOS for x86_64/arm64/ppc64le.
One issue with conda is that the ecosystem of tooling is a little fragmented. The classic “conda” package has performance issues but there is a second implementation “mamba” which fixes this at the cost of minor changes in behaviour and attempts to merge mamba into conda seem to have stalled.
If you want to try it out Id recommend using the “Mambaforge” distribution and using “mamba” for everything except “conda activate” (which is actually a shell function).
Re: Ditch your version manager
#26Earlier quoted context omitted.
Weird, since it’s not really relevant.
It is, though? Just swap "standards" with "programs"
The point behind the XKCD is that competing standards cause interoperability problems. I would argue, as does the original post, that Nix solves interoperability problems rather than creating them—it is a tool that helps you get stuff done, not a standard that purports to tell other people how they need to do things so you can get stuff done. But I’m not sure whom I’d be arguing this with, since a link to an XKCD does not constitute an argument to begin with.
Re: Ditch your version manager
#27Nix, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing. But here we are, some projects only give development instructions based on containers, others support only container based deployment. You need to go out of the way trying to convert dockerfiles into regular install/setup instructions. Containers are great and all, they s…
nix is really nice (finding it much better than homebrew cross macOS and Linux) and do good jobs at the best cost for some of my uses cases (kind of binenv / arkade, etc. that manages some binaries that the target hosts use). However, nix has its own problems that I may not qualified to comment (not savvy enough user)
- a bit of learning curve (NixOS vs nix package manager)
- memory hogging while running system-wide update
- disk space consumption is a mystery (GC & optimisation doesn't do good jobs freeing up space)
Don't get me wrong, I do like nix ;-)
Re: Ditch your version manager
#28> Nix is a tool that takes a unique approach to package management and system configuration. Nix is the basis of an OS distro: NixOS. This article is just re-articulating the idea that {the/an} OS distro should be managing this stuff, and not some fledgling language-specific programs (that go behind its back, and do a half-baked job by not controlling the packages external to their language ghetto).
I think NixOS is great, but you don’t need to switch to NixOS to use Nix. You can also install Nix on other Linux distributions or even on macOS, and use Nix to manage individual tools and projects without using it to manage your entire system.
You can also use Nix to build docker/container images, without a Dockerfile.
Re: Ditch your version manager
#29Nix, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing. But here we are, some projects only give development instructions based on containers, others support only container based deployment. You need to go out of the way trying to convert dockerfiles into regular install/setup instructions. Containers are great and all, they s…
> Containers are great and all, they solve many problems but they're not the only solution and theyre definitely not the best solution to every problem.
There a large number of developers around now who've never done traditional (RPM, DEB, SysV) packaging and don't understand it. So while the large distros like Redhat and Debian push on with it, the development community only sees Dockerfiles, Snaps, Flatpaks etc.
Re: Ditch your version manager
#30Does this work on Windows? For me, the version manager that provides the nicest experience cross-platform is Cargo from Rust. It can specify and pin specific versions. It is super easy to give to a fellow developer and have them reproduce the build. In addition, because Rust is suitable for low-level, high performance work, many times all the libraries you actually need are written in Rust and everything works very s…
Nix is very unixy so it probably could be made to work on WSL, but not native windows. Yes, if all of your dependencies are written in a single language, you can use the language-specific version manager. TFA was pointing out a solution that work across different languages.
Single user Nix works out of the box without issues on WSL.