On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton
Hello all,
I've recently had problems with haskell-src-meta. While it's a great package, it doesn't currently compile on GHC 6.12, and Matt Morrow doesn't seem to be around to push the version that does to Hackage. Our "one-world" approach with cabal seems to discourage forking as a casual act, so when a package that others rely on goes AWOL, it's very awkward to fix it.
I can think of a few ways to get around my current problems:
1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton, or something similar - this could be said to pollute the namespace, but would solve my immediate problem. I'd have to similarly specialise the chain of packages up to the one I actually want to use as well, though.
2. run my own hackage server and tell my users to use that instead.
3. ... profit?
Ideally, I'd like to be able to say something like "cabal install my-hacked-package --as original-package" - are there fundamental reasons that wouldn't be possible, or a bad idea?
I haven't (yet) run into a completely AWOL maintainer. Usually I can contact the maintainer and offer to upload a new version for them. I'm currently in this role with Takusen. I'm not the Takusen maintainer, but I expect to be uploading the next version soon as it looks like I've been given permission. I've had this happen with a couple other packages and it was always a similar situation. Negotiate with the listed maintainer to do an upload on their behalf. I've found that offering to do the work for them usually helps tremendously. And it makes a lot of practical sense. Now, what you're proposing is interesting. I believe github/patch-tag have this model? Everyone has their own branch of everything they contribute to, listed right on the website? This is inline with another idea I've heard where we'd have a 'stable' hackage and 'unstable/dev' versions. But, how does this work for resolving and communicating dependencies? On a philosophical note about cabal, cabal wants to be able to reason statically about the API (types, functions, modules) a package provides. So flags should primarily be used to configure platform specific bits necessary for compilation or implementation details, but not to change the API of a compiled library. From this point of view it seems to me that what your describing needs to be baked into either the package name or the version -- that is whatever cabal is going to look at during constraint satisfaction. I like your idea and I'd like to hear more about how we could accomplish it within the philosophical framework that cabal already has. Thanks, Jason