[gentoo-dev] Re: RFC: git-2.eclass & fetching from multiple repos

[Steven J Long]

Michał Górny wrote:
> Sometimes it is necessary for a single package to pull from multiple
> remote repositories.
<snip> 
> Another question is how to implement it API-wide. The main problem here
> is that we already use multiple values for EGIT_REPO_URI to support
> fallback URIs, and I'd prefer supporting that for the additional repos
> as well.

So currently: EGIT_REPO_URI="uri fallbackA fallbackB fallbackC"
..where A, B and C are all fallbacks for uri.

> EGIT_REPO_URI=( "repo1 fallback1" "repo2 fallback2" )

Would require you to support both the above, and the new syntax if it's an 
array. Since this is new functionality, it seems wiser to prevent confusion 
between:
  EGIT_REPO_URI=(uri fallbackA fallbackB fallbackC)
and:
  EGIT_REPO_URI=(repo1 repo2 repo3 repo4)
..and also make the implementation simpler (ie quicker for metadata), by 
using a new variable.

Semantically as well, it's the git repo for the package: in most cases 
that's all that's required, so keep it simple for the majority usage (ie 
separate.)

> 2/ Exherbo way would be doing something like:
>
EGIT_SECONDARY_REPOS='foo bar'
EGIT_foo_REPO_URI='repo1 fallback1'
EGIT_bar_REPO_URI='repo2 fallback2a fallback2b'
..
if use baz; then
   EGIT_SECONDARY_REPOS+=' baz'
   EGIT_baz_REPO_URI='repo3 fallback3'
fi

> but that would be real PITA for smart-live-rebuild, and I really hate
> dynamically named variables.
>
It's amateurishly-done as well, but there's no fixing the ugliness, nor a 
requirement for duplication, even if you fix the fail. I'd go into it, but 
technical posts I make, discussing implementation, seem to get taken as 
political, so I'll stop here, given the provenance, and stick to the RFC.

> 3/ I'm wondering about something in-between those two, supposedly:
>
> EGIT_SECONDARY_REPO_URIS=( "repo2 fallback2" ... )
>
> Still painful for s-l-r but could be implemented without
> eclass-specific hacks as array support. Of course, if we support this
> not only for fetching but for checkouts as well, it's likely to get
> unreadable as well...
>
> What are your ideas?
>
Assuming an identifier/ tag as above is useful, since you can then 
clone to a named subdirectory, or fetch from a specific repo, as directed by 
the ebuild, or fetch all except the named ones, which might be fetched into 
a different base-directory when the caller has cd'ed there, etc, extend your 
last one with optional tags:

EGIT_SECONDARY=("foo@ repo1 fallback1" "repo2 fallback2a fallback2b")
..
use baz && EGIT_SECONDARY+=("baz@ repo3 fallback3")

So, fake associative arrays in a less cluttered fashion than 2/, that are 
simple to lex in-script, and don't lead to visual or mental overload.

Since tags are optional, this accepts the same format, and extends it only 
when the ebuild needs a tag, so simple builds stay simple. The @ symbol is 
not valid in url's iirc, leave alone git uris, and draws attention to the 
named items. It preserves ordering, which an associative array won't, and 
you only ever have to worry about one variable name. Nor is there any issue 
with making sure tags and variables are in sync. (DRY.)

The simple tag enables all the stuff I mentioned above, and by giving the 
ebuild author a symbolic reference which can be passed around, it can be 
extended ad-hoc.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)