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.
Cheers,
Gary
