lazr.restfulclient

Bug #848831
Comment #8

Comment 8 for bug 848831

Revision history for this message

Benji York (benji) wrote on 2011-09-15: Re: [Bug 848831] Re: Tests do not run after successful buildout

On Wed, Sep 14, 2011 at 3:41 PM, Robert Collins
<email address hidden> wrote:
> On Thu, Sep 15, 2011 at 1:22 AM, Benji York <email address hidden> wrote:
>> On Tue, Sep 13, 2011 at 4:27 PM, Robert Collins
>> <email address hidden> wrote:
>>> Our platform is Python on Ubuntu, not virtualenv on python on Ubuntu,
>>> so this not working is a pretty big deal, not an expected situation to
>>> avoid.
>>
>> To be sure I'm being clear: I'm talking about development not usage.
>>
>> Unfortunately given the limitations of Python's module system I don't
>> know of a way to avoid conflicts with system-installed packages like
>> this bug represents (or not, see below).
>>
>> Addressing the system Python problem was the intent of Gary's work on
>> buildout 1.5. Unfortunately that work hasn't found the acceptance we
>> had hoped for and is being removed in buildout 2.0.
>
> Yup, I'm talking development too - we deploy LP as we develop it
> though (for a variety of good reasons but mainly to avoid last minute
> surprises). So things that are worrying in dev... are worrying in prod
> :)

Ah, now I see where you're coming from. You are thinking in the context
of LP, while I was thinking of developing the individual package.

> For instance, we can't guarantee that some other packaged bit of
> software won't drag lazr.uri in on a prod server. If that would break
> our other deployed code, that would be a nasty surprise!

Indeed. Given a context of LP that's certainly something to worry
about. I /think/ the best way to deal with that is to treat the
individual Python projects (lazr.*) as isolated things when developing
them (i.e., using a clean Python or virtualenv) and treat LP as a part
of a larger whole that includes those packages and the system it is
running on top of.

I think your point -- and a good one it is -- is that our best bet is
for our LP development environments reflect the production systems as
best as is practical.

(I'm getting far afield of this bug now. I wonder if I should have
replied to the list instead.)
--
Benji York

On Wed, Sep 14, 2011 at 3:41 PM, Robert Collins
<848831@bugs.launchpad.net> wrote:
> On Thu, Sep 15, 2011 at 1:22 AM, Benji York <benji@benjiyork.com> wrote:
>> On Tue, Sep 13, 2011 at 4:27 PM, Robert Collins
>> <848831@bugs.launchpad.net> wrote:
>>> Our platform is Python on Ubuntu, not virtualenv on python on Ubuntu,
>>> so this not working is a pretty big deal, not an expected situation to
>>> avoid.
>>
>> To be sure I'm being clear: I'm talking about development not usage.
>>
>> Unfortunately given the limitations of Python's module system I don't
>> know of a way to avoid conflicts with system-installed packages like
>> this bug represents (or not, see below).
>>
>> Addressing the system Python problem was the intent of Gary's work on
>> buildout 1.5.  Unfortunately that work hasn't found the acceptance we
>> had hoped for and is being removed in buildout 2.0.
>
> Yup, I'm talking development too - we deploy LP as we develop it
> though (for a variety of good reasons but mainly to avoid last minute
> surprises). So things that are worrying in dev... are worrying in prod
> :)

Ah, now I see where you're coming from.  You are thinking in the context
of LP, while I was thinking of developing the individual package.

> For instance, we can't guarantee that some other packaged bit of
> software won't drag lazr.uri in on a prod server. If that would break
> our other deployed code, that would be a nasty surprise!

Indeed.  Given a context of LP that's certainly something to worry
about.  I /think/ the best way to deal with that is to treat the
individual Python projects (lazr.*) as isolated things when developing
them (i.e., using a clean Python or virtualenv) and treat LP as a part
of a larger whole that includes those packages and the system it is
running on top of.

I think your point -- and a good one it is -- is that our best bet is
for our LP development environments reflect the production systems as
best as is practical.

(I'm getting far afield of this bug now.  I wonder if I should have
replied to the list instead.)
-- 
Benji York