Use setuptools.find_packages #2897

New Issue

exarkun · 2017-08-07T23:54:58Z

exarkun commented

2017-08-07 23:54:58 +00:00

It's less complex than manually maintaining a list of packages.

exarkun added the

labels 2017-08-07 23:54:58 +00:00

exarkun added this to the undecided milestone 2017-08-07 23:54:58 +00:00

exarkun commented

2017-08-07 23:56:37 +00:00

I looked through vcs history and found that setup.py used to use find_packages but it was removed either without an explanation or with an incorrect one:

This uses explicitly enumerated packages= and package_data= arguments to
setup(), rather than relying upon the convenient (but darcs-specific)
functions which would determine these values by asking the revision-control
system.

The possibilities seem to be that someone mistakenly thought find_packages was darcs-specific or that they didn't bother to explain the real problem with it.

I checked out the current behavior and found that it produces exactly the same install as current master@HEAD so there doesn't seem to be any reason not to use it now.

I looked through vcs history and found that setup.py used to use find_packages but it was removed either without an explanation or with an incorrect one: > This uses explicitly enumerated packages= and package_data= arguments to setup(), rather than relying upon the convenient (but darcs-specific) functions which would determine these values by asking the revision-control system. The possibilities seem to be that someone mistakenly thought `find_packages` was darcs-specific or that they didn't bother to explain the real problem with it. I checked out the current behavior and found that it produces exactly the same install as current master@HEAD so there doesn't seem to be any reason not to use it now.

exarkun commented

2017-08-07 23:57:37 +00:00

(https://github.com/tahoe-lafs/tahoe-lafs/pull/433)

exarkun commented

2017-08-08 12:23:20 +00:00

Exhibit A regarding the VCS-independence of find_packages (the implementation; find_packages itself is an alias):

https://github.com/pypa/setuptools/blob/a9d902519680132493176106fe46aa9d77eafd10/setuptools/*init*.py#L34-L101

Exhibit A regarding the VCS-independence of `find_packages` (the implementation; `find_packages` itself is an alias): <https://github.com/pypa/setuptools/blob/a9d902519680132493176106fe46aa9d77eafd10/setuptools/*init*.py#L34-L101>

warner commented

2017-08-08 20:35:47 +00:00

Yeah, once upon a time I think find_packages was VC-specific, or maybe setuptools_darcs looked for it. I see the setuptools docs say that this now looks for *init*.py, so it sounds good to me.

I'll land the PR in a moment.

Yeah, once upon a time I think find_packages was VC-specific, or maybe `setuptools_darcs` looked for it. I see the [setuptools docs](https://setuptools.readthedocs.io/en/latest/setuptools.html#using-find-packages) say that this now looks for `*init*.py`, so it sounds good to me. I'll land the PR in a moment.

warner added

code

and removed

unknown

labels 2017-08-08 20:35:47 +00:00

warner modified the milestone from undecided to 1.13.0

2017-08-08 20:35:47 +00:00

Brian Warner <warner@lothar.com> commented

2017-08-08 20:36:18 +00:00

In b2f7d8d/trunk:

Merge PR433: setup.py should use find_packages

closes ticket:2897

In [b2f7d8d/trunk](/tahoe-lafs/trac-2024-07-25/commit/b2f7d8d9f90a493106e9296f5b2f2862fd0484d0): ``` Merge PR433: setup.py should use find_packages closes ticket:2897 ```

tahoe-lafs added the

fixed

label 2017-08-08 20:36:18 +00:00

tahoe-lafs closed this issue

2017-08-08 20:36:18 +00:00

warner commented

2017-08-09 01:13:05 +00:00

Oh, one other historical note, we used to have a twisted.plugins file, for a Trial plugin that handled code-coverage. And also a src/buildtest/test_build_with_fake_dist.py, for some sort of exotic test of our bespoke virtualenv-like implementation. Both of those might have led us away from using find_packages() in the past.

Oh, one other historical note, we used to have a `twisted.plugins` file, for a Trial plugin that handled code-coverage. And also a `src/buildtest/test_build_with_fake_dist.py`, for some sort of exotic test of our bespoke virtualenv-like implementation. Both of those might have led us away from using `find_packages()` in the past.

Sign in to join this conversation.