fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Feb 06, 2013 at 04:39:47PM +0000, David Ham wrote:
> Hi Martin,
> We're not amazingly happy about that idea.
> The design of FEniCS as I understand it provides a series of tools
> which *can* be used in conjunction but need not be. In particular, our
> toolchain (which currently revels in the name flop.py) employs UFL,
> FFC, FIAT and Instant, but not UFC or Dolfin (since we employ PyOP2
> and Fluidity in those roles). Merging the repositories would give us a
> de facto Dolfin dependency which we don't need. It also more generally
> undermines the stand-alone nature of these tools and undermines the
> idea that these are generic tools which might usefully be used by
> solvers other than Dolfin (eg the UFL Dune project we heard about a
> while back).

We could make installation targets for specific subpackages (those you
mention) and add tests run by the buildbot that those can actually be
installed and used (for a set of test problems of your choice) without
needing to build DOLFIN.

The reason I suggested this in the first place was after sitting 5
people for one whole day making the releases of DOLFIN, FFC, FIAT,
Instant, UFC, UFL. It sounds ridiculous but there is something like 20
different steps to go through for each release (including pressing
buttons on Launchpad) so it's a big hassle for anyone wanting to make
a release. Then multiply that by a factor 6 and realize why we don't
make releases that often...

Another issue is working on new features. The same factor of 6 (or
more commonly only just 3-4) applies there.

We started out with 2 projects (DOLFIN + FIAT) which naturally were
separate (one C++ library and one Python library). Then we added FFC
and SyFi and UFL and UFC were added as a glue between the different
form compilers. At the time, this was an efficient way to collaborate
and allow different groups to work independently on interoperable
codes. The situation has since changed. Now most core developers touch
all the codes all the time so a common repository would be more
convenient.

The reason for the proposed change is all about making life more
convenient for developers and cutting down on administrative overhead.

> I am also concerned that having them all in the same repository would
> tempt people to break tool orthogonality by introducing
> cross-dependencies which are not necessary but might appear convenient
> to the coder at the time. This would potentially turn a de facto
> dependency into a real one and could really make our life hard.

We will likely see code being moved from one place to the other, but
cross-dependencies could likely be avoided by introducing new tests.
One particular test would be to check that the UFL unit tests and the
FIAT unit tests run without installation of any of the other packages.

--
Anders



>> Whether to merge all fenics projects into one repository was discussed
>> offline in january, my tests of today show that it is definitely feasible.
>>
>> Before we eventually do that, we should allow some time for people to
>> foresee eventual issues, e.g. we'll need changes to the buildbot, which
>> projects should be included, etc.
>>
>> The blueprint interface is not really a good place to discuss, as it doesn't
>> handle concurrent access by multiple users, so chip in on this thread if you
>> have anything to say.
>>
>> Here's a summary of pros and cons:
>> https://blueprints.launchpad.net/fenics/+spec/combine-projects-into-one-repository
>> including a link to an already merged repository prototype and a script to
>> create it.
>>
>> Martin