On 9/27/12, Branko Čibej <[email protected]> wrote: > On 27.09.2012 22:13, Olemis Lang wrote: >> On 9/27/12, Branko Čibej <[email protected]> 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 ) + testrun.org . 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 . [...] -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
