On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton <mwot...@gmail.com> wrote:
> 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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
