bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: installation procedure
Date Fri, 28 Sep 2012 11:03:42 GMT
On 28/09/12 06:05, Olemis Lang wrote:
> 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

As you say, that was only an inconsistency, I believe the source in 
question was not in the src folder and it was not expected to be.

>> 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 ...) .

The pip command currently only deals with source, not eggs, but the form 
that the source can take is varied as you can specify

  * a local directory
  * from a version control system
  * link to a tarball or zipped file (which could also be pre-download)
  * just the package name (which searches pypi or similar to provide the
    tarball/zip file)

or something like that.

> 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 .
I am not convinced that we should be responsible for making external 
source tarballs available ourselves. I also do not want to have to worry 
too much about dependency management. As long as it is clear what 
versions of plugins are appropriate for a given version of Bloodhound. I 
am really hoping that we don't need to complicate our lives too much.

So, with respect to the OSX installation, yes, the higher bar of 
installing the xcode command line tools when using virtualenv is fine. 
It would be nice for us to point out the options in documentation.

A big part of the goal here is to get to a point where the installation 
documentation is easy to maintain for both developers and the nitpicking 
advanced users; the less we need to alter installation instructions 
between releases the better.

It would be good for us to be going down a route that gets the advanced 
user installers/contributors to run a command that downloads the 
requirements before actual installation. A script to download and 
massage the filenames of the requirements is tempting. The pip command 
itself seems almost capable of doing this but it seems to screw up a bit 
when dealing with downloads that are not tarballs or zips. At the moment 
there is only one dependency that would require this but I would not be 
surprised if this situation alters over time as we decide there are 
other plugins that provide essential functionality.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message