33 ms·

You can use nix to do your package management. It has many features and advantages (build speed, deterministic build environments, language agnosticism, etc), b

You can use nix to do your package management. It has many features and advantages (build speed, deterministic build environments, language agnosticism, etc), but specific to what you brought up it makes it trivial to declare a runtime dependency of package A on package B, and guarantee that as long as package A is installed, that package B will be as well, and be accessible to A. I believe it's pretty popular in the Haskell community; I do all of my Haskell development with it and use it with Python at work, where it's slowly starting to gain traction at my company.

seagreen 11y ago
Hello from NixOS:) (https://github.com/seagreen/vivaine https://github.com/seagreen/vivaine) I don't think nixpkgs is a direct solution to this problem though. (A) Sometimes you're stuck with cabal-install because the rest of the people in the project use it. Nixpkgs includes many different sets of haskell packages, but isn't designed to pull in arbitrary versions of lots of different haskell packages by default. (B) Even if the rest of the team was using a set of haskell packages compatible with one of the Nixpkgs sets, it still involves extra work to figure out what C libraries the computer you're deploying to has, and then to make sure they're packaged for Nixpkgs and build with them. I think Nixpkgs and NixOS are _fantastic_ tools, but they aren't a panacea for all haskell deployment solutions.
- thinkpad20 11y ago
  Well I certainly wouldn't call anything a panacea, but I'm not sure I'd fully agree with either of those criticisms. Having other people in the project use cabal install -- well, you can't blame a tool for other people not using it. It's true that nixpkgs doesn't track multiple versions of packages, but using the existing tooling (cabal2nix) it should be possible to fix down the versions you need. Towards the second point, nix isn't meant to figure out what C libraries you need; it's meant to let you specify exactly what those are and be confident that those will be respected.

seagreen 11y ago

Hello from NixOS:) (https://github.com/seagreen/vivaine https://github.com/seagreen/vivaine) I don't think nixpkgs is a direct solution to this problem though. (A) Sometimes you're stuck with cabal-install because the rest of the people in the project use it. Nixpkgs includes many different sets of haskell packages, but isn't designed to pull in arbitrary versions of lots of different haskell packages by default. (B) Even if the rest of the team was using a set of haskell packages compatible with one of the Nixpkgs sets, it still involves extra work to figure out what C libraries the computer you're deploying to has, and then to make sure they're packaged for Nixpkgs and build with them. I think Nixpkgs and NixOS are _fantastic_ tools, but they aren't a panacea for all haskell deployment solutions.

thinkpad20 11y ago
Well I certainly wouldn't call anything a panacea, but I'm not sure I'd fully agree with either of those criticisms. Having other people in the project use cabal install -- well, you can't blame a tool for other people not using it. It's true that nixpkgs doesn't track multiple versions of packages, but using the existing tooling (cabal2nix) it should be possible to fix down the versions you need. Towards the second point, nix isn't meant to figure out what C libraries you need; it's meant to let you specify exactly what those are and be confident that those will be respected.