[ovirt-devel] [VDSM] Handling of scripts without a .py suffix

Nir Soffer nsoffer at redhat.com
Sun May 29 11:53:41 UTC 2016


On Sun, May 29, 2016 at 12:36 PM, Dan Kenigsberg <danken at redhat.com> wrote:
> On Sat, May 28, 2016 at 03:16:10PM +0300, Nir Soffer wrote:
>> Hi all,
>>
>> We have several scripts spread in the source, typically installed in
>> /usr/libexec/vdsm.
>> We had a useless WHITELIST[1], trying to compile these scripts with python3, and
>> we have similar (but working) whitelist for pyflakes and pep8.
>>
>> To simplify the various checks, I think we need to to do this:
>> 1. Keep .py suffix for all python files
>> 2. Move all scripts to helpers/ ([2] handles storage scripts)
>> 3. During installation, strip the .py suffix.
>>
>> With these changes, we can use the various checking commands on the entire
>> source tree.
>>
>> For example, these commands check the entire tree:
>>
>>     PYTHONDONTWRITEBYTECODE=1 python3 -m compileall -f -x '(\.tox/|\.git/)' .
>>     pep8 .
>>     pyflakes .
>>
>> Thoughts?
>>
>> [1] https://gerrit.ovirt.org/58204
>> [2] https://gerrit.ovirt.org/57363
>
> Sounds good, though I'd love to keep the separation of scripts into
> their natuaral vertical. Keep storage understand storage, etc. Why are
> you piling them into one source directory?

This is a separate topic.

The helpers do not belong in the library - we should keep libv/vdsm/xxx
with only the code that is needed for the xxx package. Helpers are external
programs that should have access only to public vdsm apis, so they don't
need to and should not have access to other files inside lib/vdsm/xxx.

This also make the source easier to understand, the structure is closer to
the final structure after installation.

So we can have:

helpers/storage
helpers/virt
...

But I don't see any value in this separation, we have only about 10
helpers.

Also each directory we add adds overhead of more useless autotools
files to maintain. Look how many makefiles we got rid by moving all the
tests to one directory.

Nir



More information about the Devel mailing list