Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of brane@wandisco.com designates
 74.125.82.175 as permitted sender)
Message-ID: <5064D4E1.2010203@wandisco.com>
Date: Fri, 28 Sep 2012 00:36:17 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Re: installation procedure
References: <50647551.8060903@apache.org> <50648175.1060302@wandisco.com>
 <CAGMZAuNeHs8tgSbA680yfRHPs_8M0oLLjQoBBhd21csfX1xZ7w@mail.gmail.com>
In-Reply-To: 
 <CAGMZAuNeHs8tgSbA680yfRHPs_8M0oLLjQoBBhd21csfX1xZ7w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 27.09.2012 22:13, Olemis Lang wrote:
> On 9/27/12, Branko Čibej <brane@wandisco.com> 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
  * the common-or-garden user who downloads a binary package prepared by
    someone else

In the latter case, it's perfectly reasonable to expect the packager to
bundle eggs of the required plugins with the package, so that the
installation doesn't have to depend on downloading anything from anywhere.

When installing from source, that's a different matter. IMO it's
pefectly OK to make the bar for that /slightly/ higher (such as, e.g.,
requiring people to have Xcode cmdline tools if they want to install
into a virtualenv).

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?

On the topic of the pip requirements: it's plausible to use a separate
script to download and massage filenames (and generate requirements.txt)
for those plugins that don't have an URL that pip can digest.

-- Brane

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