Re: Unable to install bloodhound from svn, pip install fails

[Gary Martin <ga...@wandisco.com>]

On 23/08/12 08:55, Branko Čibej wrote:
> On 23.08.2012 01:55, Olemis Lang wrote:
>> On 8/22/12, Branko Čibej <br...@wandisco.com> 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 general@incubator.a.o. 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

Re: Unable to install bloodhound from svn, pip install fails

[Gary Martin <ga...@wandisco.com>]

On 09/03/2012 09:46 AM, Branko Čibej wrote:
> On 03.09.2012 03:48, Gary Martin wrote:
>> There is another interesting alternative that I noted from a
>> conversation on general@incubator.a.o. 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.
> Subversion had such a deps signed source package before it came to
> Apache; later we discontinued that because some optional dependencies do
> not have a compatible license, so instead we ship a script that
> downloads the dependencies.
>
> License issues may prevent Bloodhound from releasing such a source
> package, but you'd know more about the details of that.
>
> -- Brane
>

I believe that none of these packages have any licensing issues for us. 
That may not be enough justification for implementing such a scheme 
though. The availability of the deps source tarball pretty much 
guaranteed when the main source tarball is available is quite 
attractive, along with any advantage from the deps package being signed 
as a whole.

Cheers,
     Gary

Re: Unable to install bloodhound from svn, pip install fails

[Branko Čibej <br...@wandisco.com>]

On 03.09.2012 03:48, Gary Martin wrote:
> There is another interesting alternative that I noted from a
> conversation on general@incubator.a.o. 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.

Subversion had such a deps signed source package before it came to
Apache; later we discontinued that because some optional dependencies do
not have a compatible license, so instead we ship a script that
downloads the dependencies.

License issues may prevent Bloodhound from releasing such a source
package, but you'd know more about the details of that.

-- Brane

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download