<div dir="ltr">To help to track this topic I propose to set the topic of the related patches to `setuptools-explicit`</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 2 oct. 2020 à 18:05, Herve Beraud <<a href="mailto:hberaud@redhat.com">hberaud@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Agreed +1<br><br>I'm in favor of avoiding implicit imports, it could help a lot of people to move away from doubts! </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 2 oct. 2020 à 17:39, Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 10/2/20 10:16 AM, Matthew Thode wrote:<br>
> On 20-10-02 15:40:44, Sebastien Boyron wrote:<br>
>> Hey all,<br>
>><br>
>> Almost all openstack projects are using pbr and setuptools.<br>
>><br>
>> A great majority are directly importing setuptools in the code (setup.py)<br>
>> while not explicitly requiring it in the requirements.<br>
>> In these cases , setuptools is only installed thanks to pbr dependency.<br>
>><br>
>><br>
>> Example 1: Having a look on nova code :<br>
>> <a href="http://codesearch.openstack.org/?q=setuptools&i=nope&files=&repos=openstack/nova" rel="noreferrer" target="_blank">http://codesearch.openstack.org/?q=setuptools&i=nope&files=&repos=openstack/nova</a><br>
>><br>
>> We can see that setuptools is importer in setup.py to requires pbr whereas<br>
>> neither in *requirements.txt nor in *constraints.txt<br>
>><br>
>><br>
>> Example 2: This is exactly the same for neutron :<br>
>> <a href="http://codesearch.openstack.org/?q=setuptools&i=nope&files=&repos=openstack/neutron" rel="noreferrer" target="_blank">http://codesearch.openstack.org/?q=setuptools&i=nope&files=&repos=openstack/neutron</a><br>
>><br>
>> I discovered this while making some cleaning on rpm-packaging spec files.<br>
>> Spec files should reflect the content  of explicits requirements of the<br>
>> related project.<br>
>> Until now there is no issue on that, but to make it proper, setuptools has<br>
>> been removed from all the projects rpm dependencies and<br>
>> relies only on pbr rpm dependency except if there is an explicit<br>
>> requirement on it in the project. If tomorrow, unlikely,<br>
>>   pbr evolves and no longer requires setuptools, many things can fail:<br>
>> - All explicits imports in python code should break.<br>
>> - RPM generation should break too since it won't be present as a<br>
>> BuildRequirement.<br>
>> - RPM installation of old versions will pull the latest pbr version which<br>
>> will not require anymore and can break the execution.<br>
>> - RPM build can be held by distribute if there is not setuptools<br>
>> buildRequired anymore.<br>
>><br>
>> As the python PEP20 claims "Explicit is better than implicit." and it<br>
>> should be our mantra on Openstack, especially with this kind of nasty case.<br>
>> <a href="https://www.python.org/dev/peps/pep-0020/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0020/</a><br>
>> I think we should explicitly require setuptools if, and only if, we need to<br>
>> make an explicit import on it.<br>
>><br>
>> This will help to have the right requirements into the RPMs while still<br>
>> staying simple and logical; keeping project requirements and<br>
>> RPM requirements in phase.<br>
>><br>
>> I am opening the discussion and pointing to this right now, but I think we<br>
>> should wait for the Wallaby release before doing anything on that point to<br>
>> insert this modification<br>
>> into the regular development cycle. On a release point of view all the<br>
>> changes related to this proposal will be released through the classic<br>
>> release process<br>
>> and they will be landed with other projects changes, in other words it will<br>
>> not require a range of specific releases for projects.<br>
>><br>
>> *SEBASTIEN BOYRON*<br>
>> Red Hat<br>
> <br>
> Yes, both should be included in requirements.txt if needed/used.  I'll<br>
> also add that if entry_points exist in setup.cfg you will need to have<br>
> setuptools installed as well.<br>
> <br>
> setuptools/pbr is hard to version manage, (it's managed by the venv<br>
> install done by devstack at the moment iirc).  I'm not sure we have a<br>
> way of specifying a requirement should be listed without also specifying<br>
> a version, but it could be as easy as adding it to the minimal set<br>
> (list) in the check code and having people's gate fail until they fix it :P<br>
> <br>
>  From a gentoo perspective, we've been going through and filing bugs for<br>
> similiar reasons recently (setuptools being a runtime dep as well as a<br>
> build dep).  So this hits outside of Red Hat as well.<br>
> <br>
<br>
This was the same conclusion we came to in the Oslo meeting last week. <br>
We mostly wanted to give people a chance to object before we patch <br>
bombed all of the non-compliant projects. :-)<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Hervé Beraud</div><div>Senior Software Engineer<br></div><div>Red Hat - Openstack Oslo</div><div>irc: hberaud</div><div>-----BEGIN PGP SIGNATURE-----<br><br>wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>v6rDpkeNksZ9fFSyoY2o<br>=ECSj<br>-----END PGP SIGNATURE-----<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Hervé Beraud</div><div>Senior Software Engineer<br></div><div>Red Hat - Openstack Oslo</div><div>irc: hberaud</div><div>-----BEGIN PGP SIGNATURE-----<br><br>wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>v6rDpkeNksZ9fFSyoY2o<br>=ECSj<br>-----END PGP SIGNATURE-----<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div>