On 09/12/2014 07:14 PM, Doug Hellmann wrote:
> 
> On Sep 12, 2014, at 12:03 PM, Sean Dague <s...@dague.net> wrote:
> 
>> On 09/12/2014 11:52 AM, Doug Hellmann wrote:
>>>
>>> On Sep 12, 2014, at 11:21 AM, Mike Bayer <mba...@redhat.com> wrote:
>>>
>>>>
>>>> On Sep 12, 2014, at 7:39 AM, Sean Dague <s...@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.
>>
>> You believe that unit tests are going to change in the way they run so
>> dramatically with this change that it invalidates their use?
>>
>> Do we have examples of what changes if you do and don't have pyc files
>> there?
>>
>> Remember, we're not changing integration testing with this. This is
>> solely unit testing.
>>
>> The reason I don't like "just fix it in your local env" is you are then
>> exporting the complexity to developers. For something that they should
>> really not have to get bitten by... a lot.
> 
> Adding a command to tox to remove the files would be less intrusive than 
> disabling their creation.
> 
> We have had bad experiences mixing features to produce unusual dev 
> environments that are different from the way the software really runs. All of 
> the issues we had with namespace packages were caused by a bug in that 
> implementation exposed because we were doing something unusual in devstack, 
> for example.
> 
> Adding some variation of “find $(python setup.py --name) --name ‘*.pyc’ | 
> xargs rm -f” to tox.ini before running testr solves the problem you have 
> identified without introducing any side-effects.
> 

This sounds saner to me so, I'd definitely go for this one.

(FWIW, I'm use to clean up `pyc` files by myself)

Flavio


-- 
@flaper87
Flavio Percoco

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to