On 1/2/16 Jan 2 -11:31 AM, Kambiz Darabi wrote:
On 2016-01-02 09:05 CET, Faré fahree@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 release.
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.