incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <ryan.ol...@wandisco.com>
Subject Re: [Apache Bloodhound] #161: Install fails when trac-hacks is down
Date Wed, 05 Dec 2012 08:51:57 GMT
On Tue, Nov 27, 2012 at 7:54 AM, Apache Bloodhound <
bloodhound-dev@incubator.apache.org> wrote:

> #161: Install fails when trac-hacks is down
> ------------------------+-----------------------
>   Reporter:  jdreimann  |      Owner:  gjm
>       Type:  defect     |     Status:  closed
>   Priority:  critical   |  Milestone:  Release 3
>  Component:  installer  |    Version:
> Resolution:  fixed      |   Keywords:
> ------------------------+-----------------------
>
> Comment (by olemis):
>
>  jftr
>
>  Replying to [comment:14 rjollos]:
>  [...]
>  > This had me thinking as to whether the older eggs would be retained on
>  PyPI, and even if they aren't, setuptools will probably just go out and
>  grab the latest version from PyPI, right? I wasn't sure if this had been
>  given much thought already, and whether we might want more explicit
>  control over the version being installed.
>
>  Files uploaded to PyPI will remain there for a while ;) . There should be
>  a way in requirements file to make pip install a particular version from
>  PyPI.


That seems to depend on whether the developer chooses to leave the older
packages on PyPI. TracAccountManager was released to version 0.4 last week,
and the 0.3.2 package is no longer available on PyPI (1), as far as I can
see.

I've just setup a new development environment following the instructions
(2), and not surprisingly TracAccountManager 0.4 is now installed. I tend
to think we should have more control over the upgrade of plugins, even for
the development environment. There was an issue (3) discovered and resolved
shortly after it's release that would likely have bit us.

There seem to be two issues here:
 1. Specifying the version in requirements.txt, which appears to be
straightforward (4).
 2. Keeping the older packages available for all of the plugins we depend
on as newer versions of those packages are released, in order to give us
time to evaluate the new version and upgrade bloodhound in a controlled
manner.

The latter could be addressed by either contacting the plugin developers
and asking that they keep the older versions available on PyPI for a
certain period of time, or by capturing the packages ourselves in another
location. Relying on plugin developers to keep packages available for a
certain period of time does not seem robust solution, even if the
developers are reliable.

I guess this is just getting back to the old issue we've discussed as to
whether we can rely on plugins that are outside of our control. However, it
was a slightly different issue when we were pulling tagged versions of the
source code directly from trac-hacks (or elsewhere) rather than depending
on what is posted to PyPI. Relying on the tagged version, for the most part
we only have to be concerned about the server staying online since the
tagged version is unlikely to change or go away. The packages on PyPI seem
to be mroe volatile, but there might be a quick path to improving the
situation now, if we can find some way to easily capture the released
versions.

I'm interested to hear if others think this is a problem, and if so, how we
should address this.

(1) http://pypi.python.org/pypi/TracAccountManager
(2)
https://issues.apache.org/bloodhound/wiki/BloodhoundContributing#GettingTheSource
(3) https://trac-hacks.org/ticket/10669#comment:4
(4) http://www.pip-installer.org/en/latest/requirements.html

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