#2897 closed enhancement (fixed)

Use setuptools.find_packages

Reported by: exarkun Owned by: Brian Warner <warner@…>
Priority: normal Milestone: 1.13.0
Component: code Version: 1.12.1
Keywords: Cc:
Launchpad Bug:


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

Change History (6)

comment:1 Changed at 2017-08-07T23:56:37Z by exarkun

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.

comment:3 Changed at 2017-08-08T12:23:20Z by exarkun

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


comment:4 Changed at 2017-08-08T20:35:47Z by warner

  • Component changed from unknown to code
  • Keywords needs-review removed
  • Milestone changed from undecided to 1.13.0

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.

comment:5 Changed at 2017-08-08T20:36:18Z by Brian Warner <warner@…>

  • Owner set to Brian Warner <warner@…>
  • Resolution set to fixed
  • Status changed from new to closed

In b2f7d8d/trunk:

Merge PR433: setup.py should use find_packages

closes ticket:2897

comment:6 Changed at 2017-08-09T01:13:05Z by warner

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.

Note: See TracTickets for help on using tickets.