On 9 May 2015 at 08:33, Sean Dague wrote:
> On 05/08/2015 02:48 PM, Robert Collins wrote:
>> Thats certainly possible too. Upside: if it works we know it works in
>> pip. Downside, we'll be tracking something that is in active
>> development and late-prototype /early alpha stage. This is likely to
On 10 May 2015 at 08:03, Jeremy Stanley wrote:
> On 2015-05-10 07:49:25 +1200 (+1200), Robert Collins wrote:
> [...]
>> We should do the following immediately we create a virtualenv anywhere
>> in our infra:
>> get-pip.py
>> pip install -U wheel setuptools
> [...]
>
> So... we already do install l
On 2015-05-10 07:49:25 +1200 (+1200), Robert Collins wrote:
[...]
> We should do the following immediately we create a virtualenv anywhere
> in our infra:
> get-pip.py
> pip install -U wheel setuptools
[...]
So... we already do install latest pip and setuptools in the system
context on our systems
On 10 May 2015 at 07:19, Jeremy Stanley wrote:
> On 2015-05-10 07:09:38 +1200 (+1200), Robert Collins wrote:
>> This is my understanding: We explicitly install pip latest in our jobs
>> (via get-pip, retrieved over https). Virtualenv shouldn't be version
>> sensitive at all to this since its not e
On 2015-05-10 07:09:38 +1200 (+1200), Robert Collins wrote:
> This is my understanding: We explicitly install pip latest in our jobs
> (via get-pip, retrieved over https). Virtualenv shouldn't be version
> sensitive at all to this since its not evaluating versions of
> anything.
My point was that,
On 9 May 2015 at 23:42, Jeremy Stanley wrote:
> On 2015-05-09 06:46:59 +1200 (+1200), Robert Collins wrote:
>> As I read it, we've got some tooling that isn't PEP-440 compatible
>> (https://www.python.org/dev/peps/pep-0440/#compatible-release defines
>> ~=) and as such we had to rollback the inten
On 2015-05-09 06:46:59 +1200 (+1200), Robert Collins wrote:
> As I read it, we've got some tooling that isn't PEP-440 compatible
> (https://www.python.org/dev/peps/pep-0440/#compatible-release defines
> ~=) and as such we had to rollback the intended use of that. As long
> as we identify and fix th
On 8 May 2015 at 21:36, Andreas Jaeger wrote:
> On 05/08/2015 10:12 AM, Andreas Jaeger wrote:
>>
>> On 05/08/2015 10:02 AM, Robert Collins wrote:
>>>
>>> I don't know if they are *intended* to be, but right now there is no
>>> set of versions that can be co-installed, of everything listed in
>>> g
On 05/08/2015 02:48 PM, Robert Collins wrote:
> On 8 May 2015 at 23:23, Sean Dague wrote:
>> On 05/08/2015 07:13 AM, Robert Collins wrote:
>
>>> The resolver I have doesn't preserve the '1b' feature at all at this
>>> point, and we're going to need to find a way to separate out 'I want
>>> X' fro
On 9 May 2015 at 05:51, Joe Gordon wrote:
>
>
> Once we are actually testing that all of global requirements is
> co-installable will we end up with even more cases like this? Or is this
> just an artifact of capping fro kilo?
> https://review.openstack.org/#/c/166377/
As I read it, we've got s
On 8 May 2015 at 23:23, Sean Dague wrote:
> On 05/08/2015 07:13 AM, Robert Collins wrote:
>> The resolver I have doesn't preserve the '1b' feature at all at this
>> point, and we're going to need to find a way to separate out 'I want
>> X' from 'I want X and I know better than you', which will le
On Fri, May 8, 2015 at 4:23 AM, Sean Dague wrote:
> On 05/08/2015 07:13 AM, Robert Collins wrote:
> > On 8 May 2015 at 22:54, Sean Dague wrote:
> >> I'm slightly confused how we got there, because we do try to install
> >> everything all at once in the test jobs -
> >>
> http://logs.openstack.or
On 05/08/2015 07:13 AM, Robert Collins wrote:
> On 8 May 2015 at 22:54, Sean Dague wrote:
>> I'm slightly confused how we got there, because we do try to install
>> everything all at once in the test jobs -
>> http://logs.openstack.org/83/181083/1/check/check-requirements-integration-dsvm/4effcf7/
On 8 May 2015 at 22:54, Sean Dague wrote:
> I'm slightly confused how we got there, because we do try to install
> everything all at once in the test jobs -
> http://logs.openstack.org/83/181083/1/check/check-requirements-integration-dsvm/4effcf7/console.html#_2015-05-07_17_49_26_699
>
> And it se
I'm slightly confused how we got there, because we do try to install
everything all at once in the test jobs -
http://logs.openstack.org/83/181083/1/check/check-requirements-integration-dsvm/4effcf7/console.html#_2015-05-07_17_49_26_699
And it seemed to work, you can find similar lines in previous
On 05/08/2015 10:12 AM, Andreas Jaeger wrote:
On 05/08/2015 10:02 AM, Robert Collins wrote:
I don't know if they are *intended* to be, but right now there is no
set of versions that can be co-installed, of everything listed in
global requirements.
I don't have a full set of the conflicts (becau
On 8 May 2015 at 20:39, Andreas Jaeger wrote:
> On 05/08/2015 10:02 AM, Robert Collins wrote:
>>
>> I don't know if they are*intended* to be, but right now there is no
>> set of versions that can be co-installed, of everything listed in
>> global requirements.
>>
>> I don't have a full set of the
On 05/08/2015 10:02 AM, Robert Collins wrote:
I don't know if they are*intended* to be, but right now there is no
set of versions that can be co-installed, of everything listed in
global requirements.
I don't have a full set of the conflicts (because I don't have a good
automatic trace for 'why
On 05/08/2015 10:02 AM, Robert Collins wrote:
I don't know if they are *intended* to be, but right now there is no
set of versions that can be co-installed, of everything listed in
global requirements.
I don't have a full set of the conflicts (because I don't have a good
automatic trace for 'why
I don't know if they are *intended* to be, but right now there is no
set of versions that can be co-installed, of everything listed in
global requirements.
I don't have a full set of the conflicts (because I don't have a good
automatic trace for 'why X is unresolvable' - its nontrivial).
However
20 matches
Mail list logo
