Small comparison to Haskell, nix & yarn packaging systems

[Profpatsch]

I can give examples how other ecosystems do this:

Haskell:

• Maintainer pushes new versions on hackage, where all are available
• cabal does version/dependency resolution
• There is a matrix builder which tests versions of the package against different compiler versions
• A maintainer can also upload her package to stackage, which is a coherent set of packages that work together, with LTS support

Nix:

• nixpkgs is a giant monorepo for all packages
• This way, you automatically get a semi-coherent package universe with each commit, if you test reverse dependencies of each change (which nix can do because of its hash-based properties)
• Every few months, a stable release is split of, with as many packages patched & working as possible

Haskell in nixpkgs:

• Once a week, a maintainer updates the package versions in nixpkgs
• The Stackage set is taken as base, the missing hackage packages are taken from hackage
• broken packages can be overwritten in multiple stages (e.g. disabling tests for a compiler version) until upstream fixes the bugs

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:

• The haskell matrix builder should be reusable.
• By converting 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.

[paf31]

By converting psc-package output to nix packages

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.

[Pauan]

though missing resolved versions

What do you mean? There is no version solving in psc-package, all versions are exact. Therefore the package set already behaves like a lock file.

though incompatible with Windows at the moment

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.

[hdgarrood]

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.

[alexandradeas]

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.

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.

[Profpatsch]

What would this involve? What would it gain us?

Generating a nix expression for the packages (needs a url & shasum per package). Each package would be built in a completely separate build environment and only reverse deps get rebuild if one dependency changes it’s input hash. Plus “CI” with e.g. hydra.

I don't think having psc-package require Nix is a good option

Definitely not, yes.

but someone could build a separate set of Nix packages, I expect.

Exactly. It could also be used to verify e.g. pull requests.

[avnik]

Actually nix support can be implemented as separate subcommand, which will read psc-package.json + package set and emit series of fetchgit statements.

I still have doubts, how properly pass that dependencies for purs build/psc-build build/pulp build. May be generated setup-hooks.sh which symlink sources in same manner like psc-pacakge/bower does?