Everything to install with Nix must be packaged "the Nix way", I assume? How is the breadth and quality of Nix packages? Just for fun I checked the kiwi image builder, from the openSUSE project, which I recently had some versioning problems with, and it was not there.
Ditch your version manager
31–40 of 155 posts
Re: Ditch your version manager
#32Nix, 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.
Most packaging for software was done by the distro and not the actual software authors though right?
Re: Ditch your version manager
#33Looks interesting enough... But how does one solve the issue of security level updates for some dependency language? Or when a particular version of some application reaches EOL and is no longer maintained, or theres some functionality in a newer version of Nodejs|Ruby|etc thats needed?
From what I understand this would require an update to the Nix version that supports it... but that also potentially means bumping other environmental versions as well, which might not be desired. But I suppose this would amount to the user arranging the structure of their filesystem correctly so its one "system" per dir/folder... Or is there a better way to cater to this? And I suppose this still means that the node modules, gems, etc that are being used then anyway also need to be updated after this accordingly.
From my limited understanding of Nix, it seems interesting, and the article was actually useful to me. But I cant seem to shake the feeling that this is another packaging abstraction like others before it, and while it seems like a better variant, its not much different to having X, Y and Z listed as requirements and then letting the dev go off and install such dependencies on their system, in the way that they best know how. Juniors or those new to a specific environment might not know the ecosystem so well so as to know to use rbenv or nvm or whatever, but I'm not sure how Nix solves this issue differently than one of the specific tools its replacing.
Theres clearly more to Nix than just setting up language environments, which I'm guessing is where its usefuleness really kicks in. But purely for lang env set up, I'm not sure I see a point over other tooling...
Re: Ditch your version manager
#34> 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).
the article is also pointing out that Nix can solve for multiple versions, shrink-wrapped environments, cross platform, etc, in a way that most OS distros can't. Nix is more than NixOS of course
Re: Ditch your version manager
#35Earlier 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.
Most packaging for software was done by the distro and not the actual software authors though right?
Yes, packaging has always been a distro issue never an upstream issue. At the extreme end of this you can look at Arch's saga with Visual Studio Code, since the Arch packagers want to disentangle the .asar app from the specific Electron version it ships inside of (they view Electron as a system library).
Re: Ditch your version manager
#36Nix, 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.
> 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 etc., mostly through FTP or even e-mail
- using containers and pushing images to registries (mostly due to my initiative)
However, streamlining that process on our end and eventually migrating over to containers, to where both the CI and CD are automated (or at least based on a manually invoked pipeline, when we're sure about making a release) seemed to be a no-brainer. Suddenly delivering software isn't something that takes an hour - even if needless cruft (making Jira issues manually etc.) is still there, any automation and getting rid of the human factor makes things safer and easier.
That said, it surprises me that previously no one bothered to set up their own DEB or RPM repositories, since then the clients could use the package management solutions that they're already familiar with. Any idea what are some of the reasons for it? Why doesn't everyone just make it so that their software can be installed and updated through apt/yum/...?
Re: Ditch your version manager
#37> My ideal dependency manager would allow me to specify each and every dependency
Don't you do that in Docker? I've read the sentence about Ubuntu EOL but don't really understand.
Re: Ditch your version manager
#38Looks interesting, but I don't see any benefits over using conda. And given the network effect benefit, conda seems like it will remain the more useful tool.
Re: Ditch your version manager
#39> 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, a new project that was created with "create-react-app" takes 181 MB of space on disk and has 35'894 files in it. That includes about 1467 modules, all for a relatively simple web application. It doesn't matter if you're using package.json/package.lock, or any other tool or solution out there - with that amount of dependencies you're simply not doing dependency "management" of any kind.
I'd argue that if you have >100 dependencies in your project, it's probably too big, unless you have a team that's dedicated to managing and auditing all of them. Of course, no one actually audits their dependencies when faced with such large numbers, and so what's left for most developers is to just trust what's out there.
Re: Ditch your version manager
#40Oh, an Amway-style pitch for Nix.