<br><br><div class="gmail_quote">On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton <span dir="ltr"><<a href="mailto:mwotton@gmail.com">mwotton@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello all,<br>
<br>
I've recently had problems with haskell-src-meta. While it's a great<br>
package, it doesn't currently compile on GHC 6.12, and Matt Morrow<br>
doesn't seem to be around to push the version that does to Hackage.<br>
Our "one-world" approach with cabal seems to discourage forking as a<br>
casual act, so when a package that others rely on goes AWOL, it's very<br>
awkward to fix it.<br>
<br>
I can think of a few ways to get around my current problems:<br>
<br>
1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton,<br>
or something similar - this could be said to pollute the namespace,<br>
but would solve my immediate problem. I'd have to similarly specialise<br>
the chain of packages up to the one I actually want to use as well,<br>
though.<br>
<br>
2. run my own hackage server and tell my users to use that instead.<br>
<br>
3. ... profit?<br>
<br>
Ideally, I'd like to be able to say something like "cabal install<br>
my-hacked-package --as original-package" - are there fundamental<br>
reasons that wouldn't be possible, or a bad idea?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Jason</div></div>