depending on setuptools is discouraged?
I'm noticing a trend that depending on setuptools is discouraged[1] in the install_requires of your setup.py. However, some packages like pyramid have core features that depend on pkg_resources (which is part of setuptools). Thus, we depend on it. As I've monitored distutils-sig I haven't seen any talk of separating these packages. To me, requiring the use of pkg_resources is a very valid use-case for depending on setuptools as it provides many improvements over the basic `pkgutil.get_data` API. Since I'm not aware of a workaround for this problem, and I'm seeing setuptools be categorically discouraged, perhaps I am just unaware and need to be enlightened? Thanks! [1] https://mail.python.org/pipermail/distutils-sig/2014-October/025131.html
On Oct 23, 2014, at 4:23 PM, Michael Merickel <me@m.merickel.org> wrote:
I'm noticing a trend that depending on setuptools is discouraged[1] in the install_requires of your setup.py. However, some packages like pyramid have core features that depend on pkg_resources (which is part of setuptools). Thus, we depend on it. As I've monitored distutils-sig I haven't seen any talk of separating these packages. To me, requiring the use of pkg_resources is a very valid use-case for depending on setuptools as it provides many improvements over the basic `pkgutil.get_data` API.
Since I'm not aware of a workaround for this problem, and I'm seeing setuptools be categorically discouraged, perhaps I am just unaware and need to be enlightened?
Thanks!
[1] https://mail.python.org/pipermail/distutils-sig/2014-October/025131.html _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
To be specific that post was talking about using the idiom that will automatically bootstrap setuptools when you run setup.py:: from distribute_setup import use_setuptools use_setuptools(version="0.6.49”) Projects *should* depend on setuptools in install_requires if their project itself uses something inside of setuptools as a runtime dependency (e.g. not in setup.py). --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Am 23.10.2014 um 22:38 schrieb Donald Stufft:
On Oct 23, 2014, at 4:23 PM, Michael Merickel <me@m.merickel.org> wrote:
I'm noticing a trend that depending on setuptools is discouraged[1] in the install_requires of your setup.py. However, some packages like pyramid have core features that depend on pkg_resources (which is part of setuptools). Thus, we depend on it. As I've monitored distutils-sig I haven't seen any talk of separating these packages. To me, requiring the use of pkg_resources is a very valid use-case for depending on setuptools as it provides many improvements over the basic `pkgutil.get_data` API.
Since I'm not aware of a workaround for this problem, and I'm seeing setuptools be categorically discouraged, perhaps I am just unaware and need to be enlightened?
Thanks!
[1] https://mail.python.org/pipermail/distutils-sig/2014-October/025131.html _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
To be specific that post was talking about using the idiom that will automatically bootstrap setuptools when you run setup.py::
from distribute_setup import use_setuptools use_setuptools(version="0.6.49”)
Projects *should* depend on setuptools in install_requires if their project itself uses something inside of setuptools as a runtime dependency (e.g. not in setup.py).
I don't know about many packages needing setuptools as a runtime dependency. Most packages need a dependency on pkg_resources only. So adding a pkg-resources egg would be nice.
On Oct 23, 2014, at 4:47 PM, Matthias Klose <doko@ubuntu.com> wrote:
Am 23.10.2014 um 22:38 schrieb Donald Stufft:
On Oct 23, 2014, at 4:23 PM, Michael Merickel <me@m.merickel.org> wrote:
I'm noticing a trend that depending on setuptools is discouraged[1] in the install_requires of your setup.py. However, some packages like pyramid have core features that depend on pkg_resources (which is part of setuptools). Thus, we depend on it. As I've monitored distutils-sig I haven't seen any talk of separating these packages. To me, requiring the use of pkg_resources is a very valid use-case for depending on setuptools as it provides many improvements over the basic `pkgutil.get_data` API.
Since I'm not aware of a workaround for this problem, and I'm seeing setuptools be categorically discouraged, perhaps I am just unaware and need to be enlightened?
Thanks!
[1] https://mail.python.org/pipermail/distutils-sig/2014-October/025131.html _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
To be specific that post was talking about using the idiom that will automatically bootstrap setuptools when you run setup.py::
from distribute_setup import use_setuptools use_setuptools(version="0.6.49”)
Projects *should* depend on setuptools in install_requires if their project itself uses something inside of setuptools as a runtime dependency (e.g. not in setup.py).
I don't know about many packages needing setuptools as a runtime dependency. Most packages need a dependency on pkg_resources only. So adding a pkg-resources egg would be nice.
As oh right now pkg_resources is part of setuptools, it’s only the downstream folks who split them apart. There are some decisions to make regarding splitting them out that I don’t know how setuptools wants to handle it. However once the stuff that pkg_resources provides is standardized it will be available as part of https://warehouse.python.org/project/packaging/ so projects wishing to use the standards based functionality (most of which is heavily inspired if not outright “stolen” from setuptools/pkg_resources) will be able to use that eventually. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Thu, Oct 23, 2014 at 3:50 PM, Donald Stufft <donald@stufft.io> wrote:
As oh right now pkg_resources is part of setuptools, it’s only the downstream folks who split them apart. There are some decisions to make regarding splitting them out that I don’t know how setuptools wants to handle it.
However once the stuff that pkg_resources provides is standardized it will be available as part of https://warehouse.python.org/project/packaging/ so projects wishing to use the standards based functionality (most of which is heavily inspired if not outright “stolen” from setuptools/pkg_resources) will be able to use that eventually.
It's great to hear that some work is being done on splitting them out, thanks for the response!
On 24 October 2014 07:07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Matthias Klose wrote:
Most packages need a dependency on pkg_resources only. So adding a pkg-resources egg would be nice.
I thought that making pkg_resources a separate thing was one of the goals of the new distutils regime. Has it not happened yet?
My understanding is that setuptools currently faces its own bootstrapping problems if pkg_resources is separated out. The accepted PEP 477 will backport ensurepip to Python 2.7.9+, at which point "python -m ensurepip && python -m pip install --upgrade setuptools" should reliably cover the bootstrapping problem even with pkg_resources separated out. That said, there also isn't a current setuptools issue to split them, so I don't know where this currently sits on Jason's priority list (setuptools itself really isn't that big a deal as a runtime dependency - the thing you don't want on your production servers is the compilers that setuptools needs in order to do anything useful with extension module source files). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Donald Stufft -
Greg Ewing -
Matthias Klose -
Michael Merickel -
Nick Coghlan