Open Stack

On Sep 12, 2014, at 11:21 AM, Mike Bayer <mbayer at redhat.com> wrote:

> 
> On Sep 12, 2014, at 7:39 AM, Sean Dague <sean at dague.net> wrote:
> 
>> I assume you, gentle OpenStack developers, often find yourself in a hair
>> tearing out moment of frustration about why local unit tests are doing
>> completely insane things. The code that it is stack tracing on is no
>> where to be found, and yet it fails.
>> 
>> And then you realize.... that part of oslo doesn't exist any more....
>> except there are still pyc files laying around. Gah!
>> 
>> I've proposed the following to Nova and Python novaclient -
>> https://review.openstack.org/#/c/121044/
>> 
>> Which sets PYTHONDONTWRITEBYTECODE=true in the unit tests.
> 
> my VPN was down and I didn’t get this thread just now, but I am strongly -1 on this as added to tox.ini, my response is http://lists.openstack.org/pipermail/openstack-dev/2014-September/045873.html.
> 
> Short answer: if you want this feature, put PYTHONDONTWRITEBYTECODE into *your* environment.  Don’t force it on our automated tests or on my environment.   .pyc files make a difference in behavior, and if we banish them from all testing, then our code is never tested within the environment that it will normally be run in after shipment.
> 
> I’d far prefer a simple script added to tox.ini which deletes orphaned .pyc files only, if a change to tox.ini must be made.

I have to agree with Mike here. Cleaning up our dev environments using a little automation is better than disabling a feature of the interpreter that may have unforeseen consequences in behavior or performance. The more we introduce unusual settings like this into our environments and tools, the more edge cases and weirdness we’re going to find in those tools that keep us from doing the work we really want to be doing.

We could use a git hook (see my earlier message in this thread) or we could add a command to tox to remove them before starting the tests. Neither of those solutions would affect the runtime behavior in a way that makes our dev environments fundamentally different from a devstack or production deployment.

Doug