Gentoo Archives: gentoo-dev

From: Steven J Long <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: RFC: git-2.eclass & fetching from multiple repos
Date: Sun, 20 May 2012 11:37:01
Message-Id: jpaktg$vvv$
In Reply to: [gentoo-dev] RFC: git-2.eclass & fetching from multiple repos by "Michał Górny"
Michał Górny wrote:
> Sometimes it is necessary for a single package to pull from multiple > remote repositories.
> 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 ;-)