Use setuptools.find_packages

[exarkun]

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

[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.

[exarkun]

​https://github.com/tahoe-lafs/tahoe-lafs/pull/433

[exarkun]

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]

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.

[Brian Warner <warner@…>]

In b2f7d8d/trunk:

Merge PR433: setup.py should use find_packages

closes ticket:2897

[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.