Nix Flakes are easier to manage than niv though.
Ditch your version manager
41–50 of 155 posts
Re: Ditch your version manager
#42> My ideal dependency manager would allow me to specify each and every dependency that is required to work on my projects. It should be easily reproducible, declarative and easy to upgrade. To me it feels like what's left out here is the fact that you need the amount of dependencies that you have to be reasonable in the first place, otherwise no single piece of software is going to help you all that much. For example…
You're not wrong, but that's a different problem. Nix makes sure that you get a predictable and reproducible tree of dependencies, and allows different applications to depend on different versions of the same dependencies. That is, it's a solution to DLL hell. It's solid engineering based on solid theory, and it really does let you manage configuration with a level of reliability that most other package managers only pretend to have.
Now auditing dependencies, knowing that the packages you depend on aren't malicious and have no known vulnerabilities... well, that's a whole separate problem. And yeah, we don't really have a solution to that right now. The best we can do, as you say, is keep the attack surface small.
But if we did try to solve the auditing problem, the solution would have to sit on top of nix or something like it. If you can't precisely specify a dependency graph and reliably install from that specification, it doesn't matter how good your auditing is or what sort of system of trust you can create. You don't know what you're getting anyway.
Re: Ditch your version manager
#43Nix, 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, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing.
Interesting viewpoint! What are your arguments for this being a better solution than containerization?
Re: Ditch your version manager
#44Earlier quoted context omitted.
> 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.
> There a large number of developers around now who've never done traditional (RPM, DEB, SysV) packaging and don't understand it. I'm one of these developers (at least as far as my day job is concerned) and the only methods of delivery in a professional context that i've seen have been: - delivering .jar or .war application files (Java), mostly through FTP or even e-mail - delivering other files, like documentation e…
Somebody replied to a post of mine in a thread like this years ago stating that he was converting every Ruby gem in his dependencies into a .deb and he was installing them with apt. That was the right way to do and everybody else is doing it wrong. I don't remember if I replied but the sheer amount of work is astounding.
Re: Ditch your version manager
#45Nix, 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, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing. Interesting viewpoint! What are your arguments for this being a better solution than containerization?
Most package managers running in containers (whether apt, apk, or something else) aren't built for reproducibility, so doing e.g. `apt update && apt install neovim` can change the versions of libraries inside the container. Furthermore, people don't (in general) write Dockerfiles for reproducibility -- it's very rare to see one where the `apt install` command (or equivalent) has exact version numbers specified for all dependencies, the FROM command uses a hash, etc.
Re: Ditch your version manager
#46Managing 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…
The obvious answer is that every customer runs a different Ruby and not every customer pays to upgrade it at the same time. I currently have customers and personal projects with any Ruby from 2.4 from 3.0. I'm not upgrading that Ruby 2.4 project for free so it's going to stay like that for a long time.
Yeah, a ruby -2.4 switch would be nice but then every gem should pick its dependencies from back at the 2.4 time. Some could be dead by now. Actually those old projects usually get updated when the OS reaches end of life and they can't install the software on the new OS.
So economical and people reasons, not technical ones.
Re: Ditch your version manager
#47I had the feeling this would be an ad for Nix after reading the first few paragraphs.
Is there really a difference from the Docker example given (“your Ubuntu version is EOL”) though? Any of your language or tools can be EOL’ed even if installed via nix, and you have the exact same problem in your hands.
Re: Ditch your version manager
#48Earlier quoted context omitted.
> Nix, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing. Interesting viewpoint! What are your arguments for this being a better solution than containerization?
Most package managers running in containers (whether apt, apk, or something else) aren't built for reproducibility, so doing e.g. `apt update && apt install neovim` can change the versions of libraries inside the container. Furthermore, people don't (in general) write Dockerfiles for reproducibility -- it's very rare to see one where the `apt install` command (or equivalent) has exact version numbers specified for al…
Are there any examples of people doing this? Sounds interesting
Re: Ditch your version manager
#49Nix, 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, guix and traditional package managers that support multiple versions (like dnf) are better solutions than just containerizing the whole thing. Interesting viewpoint! What are your arguments for this being a better solution than containerization?
Your software is first a separate application running on the OS.
But gradually over time as its usage increase and it's extended by more and more even larger applications -- your app will turn into part of the OS. Containerizing your app doesn't help in this case.
Imagine how many services from the OS you are using. Next imagine each one running in a different container and you have to build your app using 100s such containers.
Re: Ditch your version manager
#50Managing 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…
> Why can't I just run Ruby 3.0 with a flag that tells it to emulate Ruby 2.6? Or 1.8 for that matter?
My understanding is that Perl 5 supports this, for any version of Perl released in the 1994-2021 range, but in large part because it hasn't had drastic changes in that time period.