Issues with new testing scripts
rpgoldman at sift.net
Sat Jan 2 18:42:07 UTC 2016
On 1/2/16 Jan 2 -11:31 AM, Kambiz Darabi wrote:
> On 2016-01-02 09:05 CET, Faré <fahree at gmail.com> 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
No, I'm sorry, proliferation of branches is a non-starter. I am
unwilling to spend time harmonizing a "developer" branch with a stripped
down distribution branch before releasing. If people don't want the
developer stuff they can either pull and not pull the ext/ or they can
just get the tarball.
Similarly, proliferation of repositories is unacceptable.
If switching to git-subtree imposes too much cost on non-developers, we
can simply stick to git submodules. They have their issues, but any
change at this point requires not just an argument from tidiness, but a
strong argument for being wildly better. Not a little better like
better but for this annoying squash thing, but WILDLY, magically better.
Right now, I find just getting the new CL-based tools to work everywhere
is a slog. I've been spending all of my available ASDF time lately
wrestling with added complexities that are "meta" to ASDF, leaving me
with no time to work on ASDF itself. I'm not willing to add more
cognitive burden or overhead.
Sorry -- I appreciate your work to improve the process, Kambiz, but ASDF
has just turned, against my will, into an laboratory for developing a
CL-based scripting system. I am absolutely unwilling to see it turn
into a testing ground for the bleeding edge of distributed version
control, as well.
More information about the asdf-devel