opened 02:03AM - 09 Jun 25 UTC
type: enhancement
I published a few libraries on Hackage and noticed tendency in issues with
updat…ing dependencies:
- maintainer disagrees on PR
- maintainer merged PR with some changes and released version has
broken tests
- maintainer of definitely abandoned project doesn't give up
All above happened in the scope of the same project, but different dependencies!
I don't blame anybody. We are all people and tend to keep babies even when they are
orphan or dead. Successful communication assumes soft skills from both
sides, but soft skills in software is rare ;)
This situation promotes:
- merging dependency with project code base (thanks to Cabal
multi-package feature) - wasted space in repository, slow builds,
unshared maintenance burden, more RAM for HLS and dependency is not
available for others
- forking dependency - Hackage namespace pollution
- postponing project release
I see the root problem in global nature of hackage namespace.
A package author, first of all, is worried about publishing his/her
project with all dependencies in consistent state. So in the case of a
insurmountable issue with a dependency a local package fork would be
better than a full-fledged one.
Local fork benefits:
- does not affect global namespace
- instant merge - no collaboration with maintainers required
- no storage overhead for hackage
Local fork is visible in the scope of specified hackage user and
Hackage index stays unchanged. So Cabal file gets field `local-forks`
and overrides all project dependencies matching local forks of the
user.
If a project with local forks is forked - nothing should break (no
collision assumed) - local fork user is in the dependency cabal
file. And so on...
Hackage appeared before cloud repositories (e.g. GitHub) became a
thing. Today local fork could be pulled right from GitHub and local
fork feature brings no extra storage cost for Hackage founded by the community.
Local fork unblocks developers and gives a dependency maintainer time to
respond.