I would like to build a small continous integration tool.
For this purpose,
it would be graet if there was an Haskell-API for darcs,
such that one can import darcs as a Module from within Haskell
and call darcs-functions from Haskell, bypassing the commandline interface

This is the familiar libdarcs request.  We'd like to have a libdarcs,
but I want to have a safe API first.

Of  course, we could have a libdarcs that couldn't modify
repositories, and that would be inherently safe, it's just that most
requesters don't want that.

David

On Fri, Oct 17, 2008 at 5:07 AM, mafo <bugs@darcs.net> wrote:
> I would like to build a small continous integration tool.
> For this purpose,
> it would be graet if there was an Haskell-API for darcs,
> such that one can import darcs as a Module from within Haskell
> and call darcs-functions from Haskell, bypassing the commandline interface

On Fri, Oct 17, 2008 at 15:14:56 -0000, David Roundy wrote:
> Of  course, we could have a libdarcs that couldn't modify
> repositories, and that would be inherently safe, it's just that most
> requesters don't want that.

Could this be a libdarcs 0.0?

On Fri, Oct 17, 2008 at 11:20 AM, Eric Kow <kowey@darcs.net> wrote:
> On Fri, Oct 17, 2008 at 15:14:56 -0000, David Roundy wrote:
>> Of  course, we could have a libdarcs that couldn't modify
>> repositories, and that would be inherently safe, it's just that most
>> requesters don't want that.
>
> Could this be a libdarcs 0.0?

It could be.  One annoyance is that building of packages and
executables from the same object files broke between ghc 6.6 and ghc
6.8, which breaks what was originally a feature of franchise (before I
tried ghc 6.8.2).  And which means that building a libdarcs is going
to double darcs' compile time.

However, I still hold that there's little point in going to the effort
of creating a libdarcs before anyone exists to use it.  Developing a
good API is hard, and developing a good API that isn't used is close
to impossible.  The best answer to this, of course, is to use the API
ourselves, which is what I'd rather try to do first.  Once we have a
decent API used within darcs, then creating a libdarcs will make a lot
more sense.

David

The familiar request is a good sign that we have users for an eventual libdarcs.
    Concrete use cases would be welcome though.

The first application i see for a libdarcs would be to have a more evolved patch
selection/review mechanism. For example, a graphical darcs pull/whatsnew… For
this we would probably not be manipulating the repository dirtily, but we would
need to expose patch sequences, dependencies and so on.

On Tue, Oct 21, 2008 at 1:59 PM, Florent Becker <bugs@darcs.net> wrote:
>
> Florent Becker <florent.becker@ens-lyon.org> added the comment:
>
> The first application i see for a libdarcs would be to have a more evolved patch
> selection/review mechanism. For example, a graphical darcs pull/whatsnew… For
> this we would probably not be manipulating the repository dirtily, but we would
> need to expose patch sequences, dependencies and so on.

While I agree with you, I think what David was suggesting was that we
need to use our own API before we know it will work well.

I've been thinking for a while now that we're not that far from an API
at the moment.  We have the patch core, we have the repository layer
on top of that and then we have all the command logic.  The command
logic should be refactored to just depend on the repository layer.
The repository layer should just depend on the patch core.  Once we
have that then the abstractions posed by the repository layer are
meant to be the API.  Additionally, we should and could provide some
of the functionality in the commands through this API so that common
tasks for consumers of the API can be handled in ways that are
consistent with darcs itself.  I explain this as, darcs should just
become the canonical example of how to use libdarcs.  Where in reality
what I mean is that we have a libpatch and librepository to match the
layers I mentioned above.  Then libdarcs would really be a those two
libraries repackaged with some convenience functions.  All the cool
patch selection magic, revert, interactive stuff are implemented using
our UI logic that is outside of libdarcs.

One thing Eric pointed out to me on IRC is that as we converge on an
API we'll likely get it wrong.  I think this mostly comes down to
managing expectation.  We don't want to set the API in stone because
then it becomes something we don't want to use and we would have to
keep extending it to fix bugs, add features and so on.  I take this to
mean that we have to tell people it's experimental, we'll need to be
able to deprecate things and otherwise change things up without fear
of annoying projects that use the API.  I think a mature API will come
out of this process naturally.  That is to say, it will be more
painful if we try to force it to be a mature stable API.

I hope that clarifies some of my thinking.

Jason

On Tue, Oct 21, 2008 at 02:14:00PM -0700, Jason Dagit wrote:
> I hope that clarifies some of my thinking.

Which pretty much agrees with mine on this front, and was pretty
well-expressed...  so I won't write my own opinion here.

David

I'm setting this to a slightly far-off release and deferring.

We already have a libdarcs in the sense that darcs is exposed as library on
hackage.  Now we need to converge towards a proper API as Jason suggests in msg6374.

Here's a possible plan:
1. Finish type witness work
2. Split off patch library
3. Split off repository library

I suspect that we're only going to get there through constant whittling.

And a further important point: have no modules in the top level of the
name space, like Printer currently is.

Deferring for another release.