[requirements][oslo] Explicit requirement to setuptools.
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=&repo...
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=&repo...
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
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=&repo...
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=&repo...
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.
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=&repo...
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=&repo...
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. :-)
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@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=&repo...
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=&repo...
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. :-)
To help to track this topic I propose to set the topic of the related patches to `setuptools-explicit`
Le ven. 2 oct. 2020 à 18:05, Herve Beraud hberaud@redhat.com a écrit :
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@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=&repo...
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=&repo...
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-----
Le 02/10/2020 à 15:40, Sebastien Boyron a écrit :
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.
It's a good idea. I agree explicit is better than implicit. I'm interesting to help on this subject.
Hi,
Thanks Daniel for taking care of this point and contributing to it.
Daniel already opened some reviews on this subject : https://review.opendev.org/#/c/758028/
This can be tracked using topic "*setuptools-explicit*" ( https://review.opendev.org/#/q/topic:setuptools-explicit)
Hervé Beraud made a remark on review 758028:
~~~ The rationale behind these changes LGTM.
However I've some concerns related to pbr:
pbr rely on setuptools [1] and still support python2.7 [2] setuptools 50.3.0 only support python3 [3] So I wonder if we should also define a version which support python2.7 to avoid issues on with this context. setuptools dropped the support of python 2 with 45.0.0 [4] so we could use the version 44.1.1 [5] for this use case.
[1] https://opendev.org/openstack/pbr/src/branch/master/setup.py#L16 [2] https://opendev.org/openstack/pbr/src/branch/master/setup.cfg#L25 [3] https://pypi.org/project/setuptools/50.3.0/ [4] https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 [5] https://pypi.org/project/setuptools/44.1.1/ ~~~
I think it could be worth defining the version or a rule (py2 vs py3) here before performing a large series of patches.
Cheers,
*SEBASTIEN BOYRON* Red Hat
On Mon, Oct 5, 2020 at 10:31 AM Daniel Bengtsson dbengt@redhat.com wrote:
Le 02/10/2020 à 15:40, Sebastien Boyron a écrit :
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.
It's a good idea. I agree explicit is better than implicit. I'm interesting to help on this subject.
I don't think pbr uses constraints or obeys global-requirements. If it does, I don't think it should.
On 20-10-15 10:15:55, Sebastien Boyron wrote:
Hi,
Thanks Daniel for taking care of this point and contributing to it.
Daniel already opened some reviews on this subject : https://review.opendev.org/#/c/758028/
This can be tracked using topic "*setuptools-explicit*" ( https://review.opendev.org/#/q/topic:setuptools-explicit)
Hervé Beraud made a remark on review 758028:
The rationale behind these changes LGTM. However I've some concerns related to pbr: pbr rely on setuptools [1] and still support python2.7 [2] setuptools 50.3.0 only support python3 [3] So I wonder if we should also define a version which support python2.7 to avoid issues on with this context. setuptools dropped the support of python 2 with 45.0.0 [4] so we could use the version 44.1.1 [5] for this use case. [1] https://opendev.org/openstack/pbr/src/branch/master/setup.py#L16 [2] https://opendev.org/openstack/pbr/src/branch/master/setup.cfg#L25 [3] https://pypi.org/project/setuptools/50.3.0/ [4] https://setuptools.readthedocs.io/en/latest/history.html#v45-0-0 [5] https://pypi.org/project/setuptools/44.1.1/I think it could be worth defining the version or a rule (py2 vs py3) here before performing a large series of patches.
Cheers,
*SEBASTIEN BOYRON* Red Hat
On Mon, Oct 5, 2020 at 10:31 AM Daniel Bengtsson dbengt@redhat.com wrote:
Le 02/10/2020 à 15:40, Sebastien Boyron a écrit :
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.
It's a good idea. I agree explicit is better than implicit. I'm interesting to help on this subject.
On 10/2/20 3:40 PM, 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=&repo... 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=&repo... 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/ 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
Hi,
IMO, this is a problem in downstream distributions, not in OpenStack (unless this influences pip3).
In Debian, I did hard-wire an explicit build-dependency on python3-setuptools on each and every package. I don't understand why you haven't done the same thing.
If projects want to add an implicit dependency on setuptools, I'm not against it, but IMO this isn't worth the effort.
Cheers,
Thomas Goirand (zigo)
On 2020-10-15 13:22:36 +0200 (+0200), Thomas Goirand wrote: [...]
IMO, this is a problem in downstream distributions, not in OpenStack (unless this influences pip3).
In Debian, I did hard-wire an explicit build-dependency on python3-setuptools on each and every package. I don't understand why you haven't done the same thing.
[...]
And even this isn't completely necessary... it's entirely possible for projects to only use PBR and setuptools for creating packages, but use other Python stdlib methods (e.g., importlib in Python 3.8) to access version information and related package metadata during runtime.
On 20-10-15 12:56:34, Jeremy Stanley wrote:
On 2020-10-15 13:22:36 +0200 (+0200), Thomas Goirand wrote: [...]
IMO, this is a problem in downstream distributions, not in OpenStack (unless this influences pip3).
In Debian, I did hard-wire an explicit build-dependency on python3-setuptools on each and every package. I don't understand why you haven't done the same thing.
[...]
And even this isn't completely necessary... it's entirely possible for projects to only use PBR and setuptools for creating packages, but use other Python stdlib methods (e.g., importlib in Python 3.8) to access version information and related package metadata during runtime. -- Jeremy Stanley
For a large majority of packages, setuptools is required because they have entry-points. This mostly includes all the clients, but also hits some oslo packages as well.
On 2020-10-15 08:39:15 -0500 (-0500), Matthew Thode wrote:
On 20-10-15 12:56:34, Jeremy Stanley wrote:
On 2020-10-15 13:22:36 +0200 (+0200), Thomas Goirand wrote: [...]
IMO, this is a problem in downstream distributions, not in OpenStack (unless this influences pip3).
In Debian, I did hard-wire an explicit build-dependency on python3-setuptools on each and every package. I don't understand why you haven't done the same thing.
[...]
And even this isn't completely necessary... it's entirely possible for projects to only use PBR and setuptools for creating packages, but use other Python stdlib methods (e.g., importlib in Python 3.8) to access version information and related package metadata during runtime.
For a large majority of packages, setuptools is required because they have entry-points. This mostly includes all the clients, but also hits some oslo packages as well.
https://docs.python.org/3/library/importlib.metadata.html#entry-points
Maybe time to start thinking about a cycle goal around that?
On Oct 15, 2020, at 10:19 AM, Jeremy Stanley fungi@yuggoth.org wrote:
On 2020-10-15 08:39:15 -0500 (-0500), Matthew Thode wrote:
On 20-10-15 12:56:34, Jeremy Stanley wrote:
On 2020-10-15 13:22:36 +0200 (+0200), Thomas Goirand wrote:
[...]
IMO, this is a problem in downstream distributions, not in OpenStack (unless this influences pip3).
In Debian, I did hard-wire an explicit build-dependency on python3-setuptools on each and every package. I don't understand why you haven't done the same thing.
[...]
And even this isn't completely necessary... it's entirely possible for projects to only use PBR and setuptools for creating packages, but use other Python stdlib methods (e.g., importlib in Python 3.8) to access version information and related package metadata during runtime.
For a large majority of packages, setuptools is required because they have entry-points. This mostly includes all the clients, but also hits some oslo packages as well.
https://docs.python.org/3/library/importlib.metadata.html#entry-points
Maybe time to start thinking about a cycle goal around that?
The latest version of stevedore already uses importlib.metadata instead of setuptools and quite a few of the libraries and services no longer need it either.
https://review.opendev.org/#/q/topic:osc-performance+(status:open+OR+status:...)
Doug
participants (8)
-
Ben Nemec
-
Daniel Bengtsson
-
Doug Hellmann
-
Herve Beraud
-
Jeremy Stanley
-
Matthew Thode
-
Sebastien Boyron
-
Thomas Goirand