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.
I can give examples how other ecosystems do this:
Haskell:
Nix:
nixpkgsis a giant monorepo for all packagesHaskell in
nixpkgs:nixpkgsI 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-packageoutput 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.