-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Small comparison to Haskell, nix & yarn packaging systems #37
Comments
What would this involve? What would it gain us? I don't think having psc-package require Nix is a good option, but someone could build a separate set of Nix packages, I expect. |
What do you mean? There is no version solving in
I have read that Nix supports both Cygwin and Windows Subsystem for Linux. I don't use Windows myself, so I can't test this. |
Cygwin is a real pain if you try to use it in anger, and WSL is still very young. I don't think any piece of software that relies on either of those things can really be considered to support windows. |
Windows is not officially supported which means that though they might work now there's nothing to say they will work in the future. Using unsupported software should be something for the user to decide on. PS provides binaries for Windows, which means any choices around package manager should take the target audience into consideration. |
Generating a nix expression for the packages (needs a url & shasum per package).
Definitely not, yes.
Exactly. It could also be used to verify e.g. pull requests. |
Actually nix support can be implemented as separate subcommand, which will read I still have doubts, how properly pass that dependencies for |
I can give examples how other ecosystems do this:
Haskell:
Nix:
nixpkgs
is a giant monorepo for all packagesHaskell in
nixpkgs
:nixpkgs
I came to love the monorepo approach, because you automatically get a high level of consistency (provided the right CI integration) and each commit can be seen as snapshot in time. With the package-sets repo, there is already the basis for such an approach, though missing checksums and resolved versions (maybe these should be added by psc-package after resolving; see also the yarn package manager).
Another idea is to use as much already existing software from other projects as possible:
psc-package
output to nix packages, nix can be used to provide continuous integration, maybe even with https://nixos.org/hydra/.My inner programmer hates how every language under the sun reinvents package management (except of course the inner compiler-specific integration). nix is a nice meta-solution, though incompatible with Windows at the moment, so only usable as an additional layer.
The text was updated successfully, but these errors were encountered: