[requirements][oslo] Explicit requirement to setuptools.

Herve Beraud hberaud at redhat.com
Fri Oct 2 16:05:57 UTC 2020


Agreed +1

I'm in favor of avoiding implicit imports, it could help a lot of people to
move away from doubts!

Le ven. 2 oct. 2020 à 17:39, Ben Nemec <openstack at nemebean.com> a écrit :

>
>
> On 10/2/20 10:16 AM, Matthew Thode wrote:
> > On 20-10-02 15:40:44, Sebastien Boyron wrote:
> >> 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
> >
> > Yes, both should be included in requirements.txt if needed/used.  I'll
> > also add that if entry_points exist in setup.cfg you will need to have
> > setuptools installed as well.
> >
> > setuptools/pbr is hard to version manage, (it's managed by the venv
> > install done by devstack at the moment iirc).  I'm not sure we have a
> > way of specifying a requirement should be listed without also specifying
> > a version, but it could be as easy as adding it to the minimal set
> > (list) in the check code and having people's gate fail until they fix it
> :P
> >
> >  From a gentoo perspective, we've been going through and filing bugs for
> > similiar reasons recently (setuptools being a runtime dep as well as a
> > build dep).  So this hits outside of Red Hat as well.
> >
>
> This was the same conclusion we came to in the Oslo meeting last week.
> We mostly wanted to give people a chance to object before we patch
> bombed all of the non-compliant projects. :-)
>
>

-- 
Hervé Beraud
Senior Software Engineer
Red Hat - Openstack Oslo
irc: hberaud
-----BEGIN PGP SIGNATURE-----

wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
v6rDpkeNksZ9fFSyoY2o
=ECSj
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201002/bb9f7c96/attachment-0001.html>


More information about the openstack-discuss mailing list