bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: installation procedure
Date Fri, 28 Sep 2012 05:05:00 GMT
On 9/27/12, Branko ─îibej <> wrote:
> On 27.09.2012 22:13, Olemis Lang wrote:
>> On 9/27/12, Branko ─îibej <> wrote:
>>> Are we again talking about the installation procedure for the casual
>>> user?
>> I'm not sure . I thought we were preparing for cases such as t-h.o
>> down , isn't it ?
>> Otherwise what's the goal and discussion about this time ?
> There are two kinds of insatllation scenarios:
>   * the nitpicking advanced user who downloads our source and wants to
>     install Bloodhound

... maybe there's a third case which is potential project contributors
. The difference with respect to the scenario mentioned above is that
advanced users may install from sources by downloading latest tarball
, but contributors might need to check out ASF svn repos trunk . Maybe
this is the same as before , but there's a subtle disparity .

That makes me wonder (i.e. this is a question) whether Gary was
initially trying to solve a previous inconsistency between docs
(source code in src folder if pip-installing using
requirements-dev.txt) and reality (nothing under src folder) detected
by Peter some time ago

>   * the common-or-garden user who downloads a binary package prepared by
>     someone else
> The question is now what to do about downloadable plugins, and this in
> turn depends very much on how we want to do dependency version
> management. Having a cache of tarballs for the right packages "somewhere
> out there" is one option, but I have to ask, who's going to maintain that?

Exactly . I'd prefer to use links to quick jump entries (like the one
mentioned by Gary ...) in order to download plugin source code ,
because most of the time plugin releases are not quite scheduled and
its development is more ad-hoc as compared to Trac-dev schedules .
It's to be determined whether pip understands and builds raw source
code checked out frm repository under this particular situations (...
it seems not possible considering text in previous message ...) .

In general the question may be answered this way : a CI server e.g.
Jenkins , responsible for checking out plugin code and build source
tarballs if necessary and then publish somewhere . If Bitbucket only
had and API to upload download packages in the worst case (e.g. t-h.o
not available) we'd only need a combination like ( t-h.o | bitbucket )
+ . I've not setup this myself already because like I just
said , bitbucket REST API does not offer an endpoint to automate
package uploads . Nonetheless a trac instance somewhere + Trac XML-RPC
would be more than enough considering the fact that in that case Trac
RPC API actually supports file (attachments) uploads . Anyways ,
that's a starting point towards a more elaborate solution .




Blog ES:
Blog EN:

Featured article:

View raw message