Re: [Evolution-hackers] vCard test suite

[Milan Crha <mcrha redhat com>]

On Tue, 2016-04-12 at 15:30 +0100, Philip Withnall wrote:
> With a git submodule, the vCards can be re-used in other projects
> while being updated from a central repository, rather than diverging
> between all the projects.

        Hi,
right, I understand it and agree with the code sharing (data sharing,
in this case).

> I’m not sure what you mean. If the vcard-test-suite project builds
> and installs installed-tests for EDS (and other projects), what’s
> going to pull those installed tests into a system? Nobody is going to
> package vcard-test-suite for its own sake. And I wouldn’t want it to
> grow dependencies on every vCard parser library out there just so
> that it can build the tests itself.

The split of the data and the actual code which uses it just feels odd.
Naturally, one cannot live without the other. If nobody is going to
package the vcard-test-suit, then the data sharing will be avoided on
the packaging level, because each project using the data will need to
provide the data too, for example as the submodule.

With the code split, how would it work with the installed tests? We
said the data will be a soft dependency, then the test itself will be
installed only if the data will be available during the build time
(there is actually no guarantee that the data will be available also
during the execution time), or the code will be always installed, but
if it'll not find the shared data, then the test will be skipped and
will be marked as such in the test results with an explanation, thus
one might be able to notice that some more data is needed to run all
installed tests? The later makes more sense, I believe.

The thing with the soft dependency is that nobody would probably
notice. The thing with the submodule is that it doesn't help much, from
my point of view, because the real decision is going to be made on the
packaging level.

That said, I think the best thing would be to have the code in
respective vCard parsing libraries and warn if the shared data is not
available in the execution time, with a reference to the place where
the data can be found, but also look for the data on some common place,
thus the data sharing is encouraged also on the packaging level. Then
there is not needed to have submodules in the (git) repositories of the
respective vCard-parsing libraries, which the packagers might not
probably notice, because it would be a soft dependency.

I hope this makes more sense.
        Bye,
        Milan