On 23/08/12 08:55, Branko Čibej wrote:
On 23.08.2012 01:55, Olemis Lang wrote:
On 8/22/12, Branko Čibej <[email protected]> wrote:
On 22.08.2012 19:32, Gary Martin wrote:
On 08/22/2012 05:36 PM, Olemis Lang wrote:
- TracPermRedirect is not hosted in PyPI
Looks like it is there to me.
Oops !
I coudn't find it ...
:'(
[...]
IMO we should have a small package index (in ASF repository ?) in
order to provide alternate download links (e.g. PyPI , Bitbucket ,
...) to handle situations like this .
A local ASF cheeseshop might be interesting, although I don't know
whether it is something that would be difficult to argue for.
Given the ASF policy for releasing source, not binary packages, it's not
very likely to happen.
Hmmm ... It seems everything I said was not understood the way I
wanted to. So I'll try to explain myself better . I was talking about
creating somewhere (ASF repos, file attached to wiki, or somewhere
else) an index listing candidate files for downloading plugins. Just
that . Links would point to external website (e.g. t-h.o) just in a
way similar to requirements files including t-h.o URLs nowadays . The
benefit of using index file over requirements spec is mainly that it'd
be possible to state e.g. «try to download ThemeEngine from t-h.o
otherwise consider PyPI, else try unofficial Bitbucket repository,
...» . The index limited to the plugins we need to run Bloodhound . In
order to do so , afaics we could track versions of those index files
in ASF repos , isn't it ?
Yes, that's OK. Sorry I misunderstood your intent.
-- Brane
Right, I think it should be possible to create a basic package index
with a small directory tree that we can keep in our repository to check
out to some appropriate location. It also looks like it might be
possible to keep this minimal by using rewrite rules to pass unmatched
requests to pypi. I wonder if the bloodhound server itself would be
suitable for this though.
There is another interesting alternative that I noted from a
conversation on [email protected]. It seems that there is at least
one podling (Apache Stanbol) that has a 'deps' source package that is
used alongside their main release. I am not sure whether we should be
looking to a similar approach as the reasoning behind it may not match
ours. There are, however, some nice features associated with this
approach. For instance, a deps package as a whole could (presumably
must) be signed. In contrast, it seems that code signing is usually
lacking on packages on pypi - I assume that we could not provide PGP
signatures on a package by package basis with an alternate package index.
Cheers,
Gary
