Issues with new testing scripts

Kambiz Darabi darabi at
Sat Jan 2 17:31:07 UTC 2016

On 2016-01-02 09:05 CET, Faré <fahree at> wrote:

>>> One thing I *like* about submodules, is that they are optional. So if
>>> I already have regular checkouts of libraries (and I do), I can use
>>> them instead of those of make ext.
>> IMO it would be better to have fixed versions of the dependencies which
>> are used by each and every developer and packager.
>> This is in my experience the basis of a solid and reliable build.
> Yes, BUT, subtree makes it harder to distribute asdf independently
> from other libraries, which is very, very, very bad. People who use
> asdf for any serious purpose whatsoever already have their own library
> layout, packaging and versioning.

I agree fully. Only developers/packagers should need the dependencies in
ext/ and only for building and testing asdf and for nothing else.

> The last thing they want is to deal with headaches because asdf has
> another set of copies of some of the libraries that
> non-deterministically may or may not appear first when recursively
> scanning a tree. OK, since 3.1.5, the .cl-source-registry.cache should
> make that not a problem anymore. Still a potential source of confusion
> and space waste.
> One solution would be to have a "raw" repository for asdf alone, and a
> separate repository asdf-dev that uses git subtree to provide asdf and
> all its dependencies together.

Two repositories are maybe too much hassle. We could also have a master
branch which doesn't contain ext/* and is only updated with a new

Users who just git clone https://gitlab.../asdf.git would end up with
the latest stable version which doesn't contain the ext/ dependencies
and therefore don't risk to use them when asdf is checked out in a tree
which is scanned recursively.

Developers and implementation vendors should be warned explicitly about
this change and instructed to check out the correct branch before

And asdf-tools can check for existence of the dependencies in ext and
warn the developers/packagers accordingly.


More information about the asdf-devel mailing list