[darcs-users] proposal for 2.8 : fastconvert (and remark on the process)

Petr Rockai me at mornfall.net
Wed Dec 1 01:15:45 UTC 2010


Max Battcher <max.battcher at gmail.com> writes:

> On 11/30/2010 8:56 AM, Guillaume Hoffmann wrote:
>> I think now there has been enough incubation and testing for this
>> feature, and it should be included in 2.8 as subcommands of
>> ``convert``.
>> What do you think?

I am ambivalent. It is clear that merging is going to be relatively
costly, both in terms of extra work (adapting code) and lost flexibility
/ hackability. But it would make the feature more readily available to
the users.

Now, I may have a compromise approach: I have use for darcs-fastconvert
as a library anyway, so I'll work on a public API in the package and
make it available as a library component (in addition to the existing
binary). I think I am most comfortable with this: I will provide both a
tool and a library that makes it easy to implement the tool, and if
someone wants to build an alternative tool (maybe built into darcs, or a
darcs plugin if something like that comes into existence) they can use
that API.

Granted, right now darcs can't use the eventual darcs-fastconvert
library directly, since it would form a dependency cycle. Maybe that'd
be motivational to split up darcs into more packages, so the command
layer can sit on top of libdarcs and some "3rd party" libraries that
also depend on libdarcs...

I also plan to work on a repository access library that might be useful
to darcs, but will likely suffer from the same cycle issue.

> I suggest starting with the first step of getting binaries of
> darcs-fastconvert released alongside darcs releases as a plugin or
> something like "Supported Plugin" if you want to market it as
> such. Make sure that the plugin, as a plugin, is built on the
> buildbots, can be built by the platform czars, and can be released in
> all of the normal places binaries are posted to, again *as a plugin*.

It's not really a plugin, although if we model the plugin system after
git, it could be one, by the virtue of its name. I believe git foo
... just calls git-foo ... without any special considerations. (Things
work differently in hg, as far as I know.)

> I think this would be a good step in the process (external plugin -> 
> internal/contrib plugin -> (maybe) darcs built-in), a good test of the
> community infrastructure, and a clear message that plugins are supported as
> first class citizens in the darcs ecosystem rather than the past dichotomy
> between "included in darcs" and "forgotten". Middle ground, I think, would be
> useful and important to establish here, and the darcs 2.8 timeline sounds like
> a great opportunity to do so.

The process does sound a bit over-engineered to me, and also like a lot
of (extra) work for quite a few people (including myself as a buildbot
maintainer). The dichotomy is, however, already defeated, given that
darcs-fastconvert is neither included nor forgotten. Going hackage (of
darcs) and exposing the darcs modules in a library has made this
possible, I suppose.


PS: Sorry if I am a bit incoherent, I was supposed to go to bed a couple
hours ago. Going now...

More information about the darcs-users mailing list