4 ms·

I think the part that's easy to miss is that their users are devs who will want to specify their own dependencies and versions for arbitrary packages. The way

by baobun 1y ago

I think the part that's easy to miss is that their users are devs who will want to specify their own dependencies and versions for arbitrary packages. The way nix works with the way nixpkgs is structured, pinning a version of any package means pinning a commit of the entire nixpkgs tree. Since package builds of node/python/ruby packages depend on stuff outside of the package dir in the tree, you need that mapping between versions and commits. It is also a leaky abstraction, so they will need to expose that to their users, who now may run into situations where they need to align various states of the nixpkgs repo when they just wanted to "yarn add new-fancy-nodejs-package-with-linked–native-deps". Using nix without nixpkgs may be fine for more scoped use but seems hard to justify for a platform like Railway.

Nullabillity 1y ago
> Since package builds of node/python/ruby packages depend on stuff outside of the package dir in the tree, you need that mapping between versions and commits. > Using nix without nixpkgs may be fine for more scoped use but seems hard to justify for a platform like Railway. Nixpkgs isn't all-or-nothing. You're right that Nixpkgs itself rarely packages more than one version of something, but the standard approach for "language package managers" is that you use a tool like crate2nix[0] which automatically generates pinned derivations for all of your dependencies.[1] For system dependencies which aren't covered by your language package manager.. you're basically in the same position as for something like Debian: you can either pull it from Nixpkgs (and give up control beyond "which Nixpkgs am I on?") or you can write/fork your own package. Or you can pull specific packages from specific Nixpkgs checkouts and splice them into your "main" Nixpkgs version as an overlay (though this is definitely getting into the Weird Territory(tm)). [0]: https://github.com/nix-community/crate2nix https://github.com/nix-community/crate2nix [1]: For example: https://github.com/stackabletech/secret-operator/blob/30f0eb787857b47b832ff0ed06553aa21316d100/Cargo.nix https://github.com/stackabletech/secret-operator/blob/30f0eb...
- deleted 1y ago
  [deleted]
craftkiller 1y ago
> The way nix works with the way nixpkgs is structured, pinning a version of any package means pinning a commit of the entire nixpkgs tree. You can do that for a single package. For example, the latest version of linux-firmware is currently broken for my wifi cards so I pinned linux-firmware to commit dda3dcd3f of nixpkgs, whereas the rest of my software comes from the latest version of nixpkgs. There are multiple ways to accomplish this, but the way I did it was: 1. Add an input of a specific version of nixpkgs (which I called `nixpkgs-dda3dcd3f`): https://code.fizz.buzz/talexander/machine_setup/src/commit/eed2bd4f13fce8e1181f7d39c5c3ba49d96f1fb1/nix/configuration/flake.nix#L46 https://code.fizz.buzz/talexander/machine_setup/src/commit/e... 2. Add an "overlay" which replaces linux-firmware in the regular nixpkgs with the copy from nixpkgs-dda3dcd3f: https://code.fizz.buzz/talexander/machine_setup/src/commit/eed2bd4f13fce8e1181f7d39c5c3ba49d96f1fb1/nix/configuration/roles/network/default.nix#L99 https://code.fizz.buzz/talexander/machine_setup/src/commit/e...

by baobun 1y ago

Nullabillity 1y ago

> Since package builds of node/python/ruby packages depend on stuff outside of the package dir in the tree, you need that mapping between versions and commits. > Using nix without nixpkgs may be fine for more scoped use but seems hard to justify for a platform like Railway. Nixpkgs isn't all-or-nothing. You're right that Nixpkgs itself rarely packages more than one version of something, but the standard approach for "language package managers" is that you use a tool like crate2nix[0] which automatically generates pinned derivations for all of your dependencies.[1] For system dependencies which aren't covered by your language package manager.. you're basically in the same position as for something like Debian: you can either pull it from Nixpkgs (and give up control beyond "which Nixpkgs am I on?") or you can write/fork your own package. Or you can pull specific packages from specific Nixpkgs checkouts and splice them into your "main" Nixpkgs version as an overlay (though this is definitely getting into the Weird Territory(tm)). [0]: https://github.com/nix-community/crate2nix https://github.com/nix-community/crate2nix [1]: For example: https://github.com/stackabletech/secret-operator/blob/30f0eb787857b47b832ff0ed06553aa21316d100/Cargo.nix https://github.com/stackabletech/secret-operator/blob/30f0eb...

deleted 1y ago
[deleted]

craftkiller 1y ago

> The way nix works with the way nixpkgs is structured, pinning a version of any package means pinning a commit of the entire nixpkgs tree. You can do that for a single package. For example, the latest version of linux-firmware is currently broken for my wifi cards so I pinned linux-firmware to commit dda3dcd3f of nixpkgs, whereas the rest of my software comes from the latest version of nixpkgs. There are multiple ways to accomplish this, but the way I did it was: 1. Add an input of a specific version of nixpkgs (which I called `nixpkgs-dda3dcd3f`): https://code.fizz.buzz/talexander/machine_setup/src/commit/eed2bd4f13fce8e1181f7d39c5c3ba49d96f1fb1/nix/configuration/flake.nix#L46 https://code.fizz.buzz/talexander/machine_setup/src/commit/e... 2. Add an "overlay" which replaces linux-firmware in the regular nixpkgs with the copy from nixpkgs-dda3dcd3f: https://code.fizz.buzz/talexander/machine_setup/src/commit/eed2bd4f13fce8e1181f7d39c5c3ba49d96f1fb1/nix/configuration/roles/network/default.nix#L99 https://code.fizz.buzz/talexander/machine_setup/src/commit/e...