asdf-install and $vcs#

Thu, 05 Apr 2007 18:20:49 +0000

The goal is to make it simple for semi-interested hackers to track bleeding-edge on large projects (multiple asdf systems from different sources with dependencies between them).

Thoughts off the top of my head

• keep up-to-date local copies of all the bits
• allow for local changes that may or may not be fed upstream
• allow for some kind of (interactive?) conflict resolution when updating
• how do we decide where to get the source from? There may be multiple trees (forks, branches, etc) of a depended-on system, so the depending system must indicate which of them it requires.
• consider systems A and B which are developed independently and both depend on C. Assume in this example that they are both happy with the same branch of C. The user has A and C installed: when he installs B, can it/should it find the existing local copy of C or download another?
• a similar example, but this time the user has hacked C to make it work better with A. When he installs B, should it use the locally hacked version or install a fresh one? Both answers are potentially correct, depends on circumstances.
• does the answer to the last question but one change if the user was intending to hack on C when he installed B, but hadn't got around to it yet?

What if we mark depended-on systems as "shareable"/"unshareable"? Are there multiple sharing domains? If E depends on C and D, D depends on C and C is unshareable, should E use the local copy of C anyway to satisfy its direct dependency because it's already got a copy via D? Most probably. So unshareable systems should nevertheless be shared with anything that has a dependency relationship with the system that caused them to be installed.

With regard to specifying the appropriate tree: Let's consider darcs for example: a repository is a branch, but that doesn't tell us its genetics - if we have a C' branch locally, we can't determine by looking at it whether it satisfies a requirement for http://darcs.example.com/C. We need to look at the patches it contains (typically, I expect, a tag) to determine whether it's good enough. But a tag alone won't help with locating the repo in the first place, so we still need the repo url (or anyway, a repo url) as well.

We also need some kind of local registry of "places to look for C other than the official repo", which contains pointers to previously downloaded (and shareable) copies of C