haskell
local-fork field
I published a few libraries on Hackage and noticed tendency in issues with updating 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 (or github
then no changes on hackage is required at all) 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.
Wouldn't this encourage packages to go out with their own forks of other packages included within them, further fragmenting dependencies?
If this is typical, I'd love to hear of examples where this happens in other language communities.
maintainer disagrees on PR
Ok, but do they disagree with the feature? You can talk to them and agree on an alternate solution. If their library isn't extensible or composable, maybe the whole code is organized wrong, and a fork wouldn't even fix the issue.
maintainer merged PR with some changes and released version has broken tests
This is surely an accident and could be fixed by using CI or release candidates.
maintainer of definitely abandoned project doesn't give up
In this case, why should the fork be local. It should be a public fork, similar to the cryptonite/crypton situation.
