Btw, it's not a dependency conflict issue. If we install python
dependencies via pip, it's okay to be with foo>=1.5.0 in the past, but not
now maybe (oslo.util -> oslo_util breaks nearly everything). Maybe we need
a requirements.txt as release like:
foo==1.5.0
bar==2.1.0
not
for>=1.5.0
bar>=2.0.
On 27 August 2015 at 02:00, Gareth wrote:
> Hey guys,
>
> I have a question about dependencies. There is an example:
>
> On 2014.1, project A is released with its dependency in requirements.txt
> which contains:
>
> foo>=1.5.0
> bar>=2.0.0,<2.2.0
>
> and half a year later, the requirements.txt cha
Gareth,
A real example is to enable Rally for OpenStack Juno. Rally doesn't support
> old release officially but I could checkout its codes to the Juno release date
> which make both codes match. However even if I use the old requirements.txt
> to install dependencies, there must be many packages
Hey guys,
I have a question about dependencies. There is an example:
On 2014.1, project A is released with its dependency in requirements.txt
which contains:
foo>=1.5.0
bar>=2.0.0,<2.2.0
and half a year later, the requirements.txt changes to:
foo>=1.7.0
bar>=2.1.0,<2.2.0
It looks fine, but po
