41–50 of 109 posts
My main problem is that Nix is based on one version of libc. If your system already has vendor-locked libraries based on a different version of libc, then it is quite difficult to get the rest of the system on that same version of libc.
What systems have you encountered this on? (just curious; not trying to minimize)
The article mentions Guix several times but never once mentions as a pain point that Nix lacks a well-founded programming language. Now I may be a total outlier here but it seems to me that while getting the fundamental concepts right is a good thing, having powerful means of combining them becomes more important in the long run. Does that not speak in Guix' favour?
Earlier quoted context omitted.
> for example allowing to specify environment variables in manifest.scm files. There is already .envrc or .dir-locals.el? And manifest is just - well - manifest. By definition it has to be 'plain'. I mean, there are already a million ways to load env vars so why'd you want guix to do that too and from manifest.scm of all places?
Because instead of distributing two files (channels.scm and manifest.scm, or flake.lock and flake.nix), you have to execute monstruosities like `guix shell --container -m ./manifest.scm -- bash -c 'GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale LC_ALL=fr_FR.utf-8 exec jekyll build'`, which is how I build some websites I have. To me, that's not ok from an user experience point of view.
nix develop -c jekyll build
Or, for an automatic setup,
cat > .envrc
use flake
^D
cat > .envrc
if ! has nix_direnv_version || ! nix_direnv_version 2.2.0; then
source_url "https://raw.githubusercontent.com/nix-community/nix-direnv/2.2.0/direnvrc" "sha256-5EwyKnkJNQeXrRkYbwwRBcXbibosCJqyIUuz9Xq+LRc="
fi
use flake
^D
[1] https://github.com/nix-community/nix-direnv#direnv-source_ur...
Earlier quoted context omitted.
Because instead of distributing two files (channels.scm and manifest.scm, or flake.lock and flake.nix), you have to execute monstruosities like `guix shell --container -m ./manifest.scm -- bash -c 'GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale LC_ALL=fr_FR.utf-8 exec jekyll build'`, which is how I build some websites I have. To me, that's not ok from an user experience point of view.
Does nix develop -c jekyll build not do the job for you? (For a single development command—for deploy 'nix build' should be set up to do the right thing, including setting LC_ALL if necessary; and to enter a dev shell just 'nix develop' should work. Nixpkgs installs glibc with a full complement of locales by default, which has its downsides size-wise but should prevent any troubles when setting LC_ALL=fr_FR.) Or, for…
Earlier quoted context omitted.
What do you mean in pt 1? I've not experienced any issues there, but curious to hear from others.
Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest". Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and…
I agree that if the maintainers are compensated for their time, patches would be a lot more efficient in these scenarios to clean up the loose ends.
The article mentions Guix several times but never once mentions as a pain point that Nix lacks a well-founded programming language. Now I may be a total outlier here but it seems to me that while getting the fundamental concepts right is a good thing, having powerful means of combining them becomes more important in the long run. Does that not speak in Guix' favour?
It does for Guix, but it's not such a big deal in my opinion regarding Nix. Please note I didn't think about this in depth, but, yeah, of course, using Haskell or Ocaml would probably be cooler than some domain specific language. But I also believe the nix language also makes Nix more accessible at first than let's say Guile : entering into the Guix world is certainly more costly, and I feel Nix* capitalizes on this…
Earlier quoted context omitted.
Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest". Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and…
This couldn’t be any further from my experience. Instead of being told fuck off, I was offered (and later offered when I became a maintainer myself) constructive criticism, often times with the patches, required to make it up to standard, included. > maintainer says the old package works for him We’re all just volunteers, who are doing this in our free time. Usually this works well enough for most packages, but you a…
Probably you are lucky.
> always free to submit
I did. The problem is that in this particular case there is one guy with merge rights who doesn't want to update a package because it breaks something for him so the package is outdated by years. He provided me an excerpt from his logs and said that the update doesn't work for him. Period. They don't even think that the outdated package doesn't work on _modern_ hardware.
Earlier quoted context omitted.
Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest". Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and…
I can say I've had merge requests denied because I used the title "xxx: init @ 1.0.0" instead of "xxx: init at 1.0.0", but when upgrading packages you must use a symbol, either "->" or "→", but initialization doesn't allow a symbol. Nitpicky but fine, I update the commit title and I wait 2 months for approval+merge. There's also a long disconnect between approved vs. merged in general; I currently have 2 or 3 merge r…
Earlier quoted context omitted.
Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest". Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and…
> Nope, your time isn't valuable because there are too many of you and just one nix. This ... seems entirely reasonable, though? As you point out, having to do extra work on behalf of others isn't desirable. -- If a pull request is made and the maintainer(s) don't like it, the options are "reject it", "maintainer puts in extra work to accept it", "pull request author puts in extra work to get it accepted". With as ma…
Yeah. It's better to spend more time repeating "read the guidelines" instead of fixing the commit message. And of course it's better to keep critically vulnerable packages (netatalk, potential remote code execution) for months and piss off the maintainer (not me) instead of turning on the autosquash.