111–120 of 155 posts
Good introduction to Nix. I wish I would have had this when I started. But what do they mean with “works forever”? What if the Git repo or Web server of the project is gone in several years? How do you reproduce it? Does niv include a local source code mirror?
Earlier quoted context omitted.
> If that commit is still available. Why wouldn't it be available? Nix packages are on github. [1] > And that's on top the fact that "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above" That's the same as on any other host. If I write about installing ruby on ubuntu today and you read the blog post…
> Why wouldn't it be available? Nix packages are on github. [1] 1. Git history can be re-written. 2. Nix packages still point to some specific versions that may or not may be available [1] So how exactly is nix so much different from "a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore"? > That's the same as on any other host. If I write about installing ruby on u…
Maybe nix is not for you. I'm not well versed with nix packages and only use the basics.
Your answer on how to pin this package hasn't been answered good enough for you because it takes work to pin packages and it isn't as trivial as on ubuntu. To paraphrase it's a great place to live but not to visit.
Some of my friends are active in the NIX community. They mentioned that it was around as hard as learning haskell. One of them only grokked nix after he read nix pills [1].
I think nix has good concepts and in theory is the package manager I would like to use. In practice it isn't that.
Personally, I run ubuntu and use nix packages for three things:
- quickly test a program without needing to install it system wide via apt-get `nix-shell -p appname` - together with direnv for the dependencies of CPP projects I work on and - installing commandline tools packages
I think webassembly may be a solution to many of the problems with installing tools. We would need an npm like manager for all the tools/libs.
This is one of the main goals behind https://wapm.io :)
Earlier quoted context omitted.
> Why wouldn't it be available? Nix packages are on github. [1] 1. Git history can be re-written. 2. Nix packages still point to some specific versions that may or not may be available [1] So how exactly is nix so much different from "a problem with our CI/CD pipeline because an old package that's a sub dependency wouldn't install anymore"? > That's the same as on any other host. If I write about installing ruby on u…
Hey, Maybe nix is not for you. I'm not well versed with nix packages and only use the basics. Your answer on how to pin this package hasn't been answered good enough for you because it takes work to pin packages and it isn't as trivial as on ubuntu. To paraphrase it's a great place to live but not to visit. Some of my friends are active in the NIX community. They mentioned that it was around as hard as learning haske…
> Personally, I run ubuntu
What does Ubuntu have to do with it?
Here's a quote from the article:
--- start quote ---
Ditch your version manager
September 17, 2021 • 7 min read
You probably use a variety of tools to manage your Ruby, Node, Python, Elixir versions, such as rvm, rbenv, nvm, or asdf. They all work reasonably well, right?
Well, not quite.
...
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.
--- end quote ---
To this end, the author proposes to ditch rvm, rbenv, nvm etc. and go for nix.
Here's the entirety of what I need to do to pin my ruby version:
rvm install 2.1.1
rvm use 2.1.1
I've yet to see anything that approaches this in nix. We are talking about reproducible builds, aren't we?
Earlier quoted context omitted.
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 doe…
That doesn't mean it's bad, it just means that it's not going to universally cover everyone's use cases.
Earlier quoted context omitted.
First, dependency manager vs package manager. Potayto potatoh. Second. The reason I recommend direnv is because of ergonomics, so you don't have to remember to reload your shell. Most current version managers either do it themselves through shell hooks or ask you to install direnv. Point taken on using brew: I've changed it to use nix-env. Third. Yep. Sort of like having to learn English before you can learn programm…
> No other package manager can freeze the complete dependency set you are using I don't know if you realise that your post makes a poor case for that, and for imagined reproducibility of nix builds? 1. Direct quote from your post: "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above". The "solution"…
Earlier quoted context omitted.
> No other package manager can freeze the complete dependency set you are using I don't know if you realise that your post makes a poor case for that, and for imagined reproducibility of nix builds? 1. Direct quote from your post: "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above". The "solution"…
You can do version pinning with flakes: https://nixos.wiki/wiki/Flakes
1. How?
You'd think such a simple thing, especially in the context of "ditch version managers" would be easy and warrant at least an example.
So far I've had:
- ignoring the question or avoiding the answer
- one answer "just use overlays" with no example
- one answer "just use flakes" with no example
2. It's a separate, unstable feature
It amazes me that after 18 years, you still need (probably? no idea) to use some entirely separate feature that is still unstable/experimental and uses an entirely different system of describing what's needed than nix proper.
And still no answer how to do the thing that is literally required for every single reproducible build: pin a tool to a specific version.
Meanwhile tools that we're supposed to ditch are as simple as
rvm install 2.1.1
rvm use 2.1.1Earlier quoted context omitted.
First, dependency manager vs package manager. Potayto potatoh. Second. The reason I recommend direnv is because of ergonomics, so you don't have to remember to reload your shell. Most current version managers either do it themselves through shell hooks or ask you to install direnv. Point taken on using brew: I've changed it to use nix-env. Third. Yep. Sort of like having to learn English before you can learn programm…
> No other package manager can freeze the complete dependency set you are using I don't know if you realise that your post makes a poor case for that, and for imagined reproducibility of nix builds? 1. Direct quote from your post: "if you tried to follow this article step by step, you’ll have noticed that the versions of ruby and node you installed are probably slightly different from the ones above". The "solution"…
I don't see why a commit hash in insufficient to declare a package reproducible. For my system, I just use channels, but for anything mission critical, I think most people pin their commit hash of nixpkgs [0]. A pinned commit of nixpkgs will produce the exact same set of packages, forever.
> a way to actually properly pin package versions
The way you do this is to pull in a specific commit of nixpkgs (you can install packages from many versions of it at the same time, if you want). Alternatively, you can manually vendor the package file, which is what I usually do for one or two packages.
Earlier quoted context omitted.
Reading your linked post, it seems you are wrestling with how Nix works. Nix is hard to learn. The concepts used are almost the same, but different. That's because it's solving slightly different problems than package managers currently do. As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable?
> Reading your linked post, it seems you are wrestling with how Nix works. Not only me. > That's because it's solving slightly different problems than package managers currently do. We keep hearing this claim, and hardly any proof of that. > As the overriding example shows, the versions are pinned by hash and are stored in a file. What about it is not maintainable or scalable? 1. Commit hashes are not versions 2. Hun…
I believe flakes will make this a lot easier, but it's not quite here yet.
Earlier quoted context omitted.
> 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.