Open Stack

Hey all,

Almost all openstack projects are using pbr and setuptools.

A great majority are directly importing setuptools in the code (setup.py)
while not explicitly requiring it in the requirements.
In these cases , setuptools is only installed thanks to pbr dependency.


Example 1: Having a look on nova code :
http://codesearch.openstack.org/?q=setuptools&i=nope&files=&repos=openstack/nova

We can see that setuptools is importer in setup.py to requires pbr whereas
neither in *requirements.txt nor in *constraints.txt


Example 2: This is exactly the same for neutron :
http://codesearch.openstack.org/?q=setuptools&i=nope&files=&repos=openstack/neutron

I discovered this while making some cleaning on rpm-packaging spec files.
Spec files should reflect the content  of explicits requirements of the
related project.
Until now there is no issue on that, but to make it proper, setuptools has
been removed from all the projects rpm dependencies and
relies only on pbr rpm dependency except if there is an explicit
requirement on it in the project. If tomorrow, unlikely,
 pbr evolves and no longer requires setuptools, many things can fail:
- All explicits imports in python code should break.
- RPM generation should break too since it won't be present as a
BuildRequirement.
- RPM installation of old versions will pull the latest pbr version which
will not require anymore and can break the execution.
- RPM build can be held by distribute if there is not setuptools
buildRequired anymore.

As the python PEP20 claims "Explicit is better than implicit." and it
should be our mantra on Openstack, especially with this kind of nasty case.
https://www.python.org/dev/peps/pep-0020/
I think we should explicitly require setuptools if, and only if, we need to
make an explicit import on it.

This will help to have the right requirements into the RPMs while still
staying simple and logical; keeping project requirements and
RPM requirements in phase.

I am opening the discussion and pointing to this right now, but I think we
should wait for the Wallaby release before doing anything on that point to
insert this modification
into the regular development cycle. On a release point of view all the
changes related to this proposal will be released through the classic
release process
and they will be landed with other projects changes, in other words it will
not require a range of specific releases for projects.

*SEBASTIEN BOYRON*
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201002/902c1d86/attachment-0001.html>