[darcs-devel] status of darcsden repo

Ganesh Sittampalam ganesh at earth.li
Tue Feb 18 12:24:18 UTC 2020


Hi,

I was actually just drafting an email about darcsden myself, wondering
whether it would make sense to just merge it into darcs. There are quite
a lot of competing considerations, described below, but the immediate
trigger was running into the situation you describe myself, with
darcsden being outdated.

On 18/02/2020 10:14, Ben Franksen wrote:
> The official darcsden repo still requires darcs < 2.14. There are forks
> with patches to adapt it to at least darcs-2.14 but these patches mean
> that darcsden does not build against older darcs versions. Is there a
> good reason why darcsden must be source-compatible to older darcs
> versions? If not I propose we upgrade darcsden to require darcs>=2.14
> and pull the adaptions.

I agree with doing that (if we don't merge it). In practice any given
version of darcsden can only work with one major version of darcs unless
we use lots of CPP.

> BTW, there are more incompatible changes in 2.15.2. I have a version of
> darcsden that almost builds against darcs-screened. However, there is
> one incompatibility regarding http-client where darcs requires a newer
> version and this version breaks building darcsden. I am not sure how to
> fix that.

I guess we need to update darcsden or its dependencies for the latest
http-client. This is a problem we've run into before with both darcs and
darcsden development and sometimes I've ended up just taking on
maintainership of abandoned libraries to keep things working.

Coming back to the question of merging darcsden with darcs:

My idea would be to make it part of the darcs repository and as separate
executables in darcs.cabal.

There are some obvious disadvantages to the merger:

 - Keeping the darcsden code up to date will slow down darcs development

 - Darcsden dependencies might be a pain to keep up to date with
   new GHCs, or when we run into situations with http-client like you
   describe above.

 - The Darcsden tests (particularly the automated browser ones) are
   fragile and a bit of a pain to setup. But we could just not expect
   darcs developers to run them.

 - It'll increase the barriers to entry for people making contributions
   to darcsden.

For the advantages, I see this mainly as a strategic question. Do we see
it as important enough that we always want it to be working? Also I
think that in general keeping it up to date will be easier if done at
the same time as other darcs changes, and will also encourage us to
think about good abstractions for UI functionality. It also makes the
version compatibility question irrelevant.

There are also some darcs operations that I think can be done much
better in a GUI than in the command-line. I've experimented with some
ideas like this in the past, for example reordering patches in history
and automatically checking that each intermediate state builds. I didn't
submit it and it's currently languishing on an old branch of darcsden
that will be painful to bring up to date. I'm not sure that having
darcsden integrated into darcs would massively improve that, but it
wouldn't have hurt.

Design questions:

- Should the existing darcsden library (as opposed to executables/tests)
be merged into the darcs library, or left as a separate private library
using the new multiple libraries feature in Cabal 3.0?
https://fgaz.me/posts/2019-11-14-cabal-multiple-libraries

- If we merge it into the darcs library, would we keep it under the
Darcsden.* namespace or put it in something like Darcs.UI.Den.* ?

- To what extent should we make the darcsden code more darcs-ish, e.g.
make it use witnesses properly? My inclination would be to do that but
other contributors to darcsden have mentioned it would put them off
contributing.

Cheers,

Ganesh


More information about the darcs-devel mailing list