[Haskell-cafe] Handling absent maintainers
mwotton at gmail.com
Thu Jul 15 22:46:43 EDT 2010
On Fri, Jul 16, 2010 at 11:49 AM, Jason Dagit <dagit at codersbase.com> wrote:
> On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton <mwotton at gmail.com> wrote:
>> 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.
This is great when it works, but it does add friction on top of the
process of forking and experimentation. One of the things I've noticed
in myself is that I'm much more likely to try something out if I can
fork it, make my changes and start using it right away (including
distributing easily to other users). If I have to wait to go through
the gatekeeper, motivation has to be very high.
One of the interesting consequences of cheap forking is that projects
like the emacs starter kit have a very different model: it's designed
to be forked, and to have the user's personal changes committed, so
you can stay up to date without having to extract everything into a
small set of config files. This is more or less impossible under the
> 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?
In terms of Cabal? I don't know enough about it to be authoritative.
Conceptually, it seems clear enough: if you specify a variant package
explicitly by name, that one gets used - if you don't specify a
variant, use the canonical package.
So long as forking is cheap and not socially awkward, this is fine:
you fork the chain of packages you need to show that it all works, and
submit a pull request to the maintainer of the real package. If he
doesn't like it, fine - you can still use your changed version. It
might be nice to be able to mark a variant as no longer relevant once
the changes have been pulled into the parent repo, but it's a frill.
> 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.
Yes, I tend to agree.
> 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.
A UNIX signature isn't a return address, it's the ASCII equivalent of a
black velvet clown painting. It's a rectangle of carets surrounding a
quote from a literary giant of weeniedom like Heinlein or Dr. Who.
-- Chris Maeda
More information about the Haskell-Cafe