Include LICENSE.txt in wheel

[xflr6]

Initially, I thought a file with the name LICENSE.txt would be included by default.

Before:

$ python setup.py bdist_wheel
...
$ python setup.py bdist_wheel
adding 'sample\__init__.py'
adding 'sample\package_data.dat'
adding 'sampleproject-1.2.0.data\data\my_data\data_file'
adding 'sampleproject-1.2.0.dist-info\DESCRIPTION.rst'
adding 'sampleproject-1.2.0.dist-info\entry_points.txt'
adding 'sampleproject-1.2.0.dist-info\metadata.json'
adding 'sampleproject-1.2.0.dist-info\top_level.txt'
adding 'sampleproject-1.2.0.dist-info\WHEEL'
adding 'sampleproject-1.2.0.dist-info\METADATA'
adding 'sampleproject-1.2.0.dist-info\RECORD'

After:

$ python setup.py bdist_wheel
...
adding 'sample\__init__.py'
adding 'sample\package_data.dat'
adding 'sampleproject-1.2.0.data\data\my_data\data_file'
adding 'sampleproject-1.2.0.dist-info\DESCRIPTION.rst'
adding 'sampleproject-1.2.0.dist-info\LICENSE.txt'
adding 'sampleproject-1.2.0.dist-info\entry_points.txt'
adding 'sampleproject-1.2.0.dist-info\metadata.json'
adding 'sampleproject-1.2.0.dist-info\top_level.txt'
adding 'sampleproject-1.2.0.dist-info\WHEEL'
adding 'sampleproject-1.2.0.dist-info\METADATA'
adding 'sampleproject-1.2.0.dist-info\RECORD'

[gtback]

There seems to be the idea of eventually including any file named LICENSE or LICENSE.txt by default, but until then this seems like a positive change.

https://github.com/pypa/wheel/blob/3a87ecebaba765475392ae2cdfa2a51cb78360e0/wheel/bdist_wheel.py#L438-L443

[xflr6]

Thanks, can someone go ahead and merge this?

[jakirkham]

Is this ok to merge?

[jakirkham]

For some reason I forgot about this PR and started to put together my own on this same subject only to bump into this again. Could someone please merge this?

[xflr6]

@di, @pfmoore: can anyone merge?

[pfmoore]

Am I right in thinking this needs a recent version of setuptools? In particular see #56 for a discussion on this. Personally, I still think it would be nice if we were recommending a declarative approach, but I'd like feedback from @jaraco and @ncoghlan before reopening that question.

On the other hand, if we don't include the license this way, what's the alternative?

[xflr6]

AFAIU, this has been in wheel for a very long time (no requirement on setuptools) and is best practise:
pypa/wheel@0acfb4c
https://wheel.readthedocs.io/en/stable/#including-the-license-in-the-generated-wheel-file
https://github.com/pypa/wheel/blob/13d6ff3e8ef509b469d6bb6dd9cd8870ac3f2a16/CHANGES.txt#L19

[xflr6]

See e.g. these pypa projects:
https://github.com/pypa/setuptools/blob/e17cf0bda668e2e6b91251f63c13683b15efd051/setup.cfg#L26
https://github.com/pypa/pip/blob/0007825733aa862e76a66e5d1cfee121c29192ff/setup.cfg#L35
https://github.com/pypa/wheel/blob/13d6ff3e8ef509b469d6bb6dd9cd8870ac3f2a16/setup.cfg#L16

[pfmoore]

Ah, thanks for the clarification - it looks like both setuptools and wheel use the [metadata] section, and I was getting confused between the two of them.

[xflr6]

Thanks, +1 that declaraive metadata (i.e. in setup.cfg) would be nice, see e.g.:
https://github.com/rtfd/readthedocs.org/blob/0c9fafbde596f372b564d8daf29c8593b7c30e82/setup.cfg#L1-L20
https://github.com/rtfd/readthedocs.org/blob/0c9fafbde596f372b564d8daf29c8593b7c30e82/setup.py#L1-L5

[jaraco]

it would be nice if we were recommending a declarative approach

Declarative support was added to Setuptools only fairly recently (last summer perhaps?). My sense is we're starting to get to the point that we can start recommending it for projects, but I'd still include a caveat or note that to support older environments (with new releases of one's project), one must supply the parameters to setup.py. I'd personally like to see more (non-critical) vanguard projects adopt the declarative config and prove where it works and doesn't. I intend to do that with some of my projects as well soon. So I'm +1, but with some caution.

[Gadgetoid]

I'd personally like to see more (non-critical) vanguard projects adopt the declarative config and prove where it works and doesn't. I intend to do that with some of my projects as well soon. So I'm +1, but with some caution.

@jaraco I'm adopting this approach across our ecosystem of small Python hardware driver projects aimed at the Raspberry Pi and will be slowly rolling out a setup.py pattern like this - https://github.com/pimoroni/boilerplate-python/blob/master/library/setup.py - as and when I write or update libraries.

I feel like I'm treading on loose ground here, and appreciate any/all feedback.

[jaraco]

I've also began using declarative config across many projects. My boilerplate is here, with documentation about the boilerplate in skeleton.md, which links to the blog entry that describes its inception.

Note that the install_requires of setuptools will have no effect on the build/distribution/installation of that project... it will only ensure that a minimum setuptools is present after your package is installed. So you can probably omit that and simply rely on the implied setuptools.

Alternatively, and better, you should use pyproject.toml to define your build-requires - that's where you can properly declare your setuptools requirement. Here's where I declare mine. That of course requires that the installer honor that directive (pip 10 I believe was the first), but I've found in practice that most environments keep setuptools up-to-date (with a few exceptions like Raspberry Pi) or use pip 9 or later and end up installing wheels (which doesn't require setuptools). I definitely recommend uploading wheels for all of your packages for maximum compatibility.

[Gadgetoid]

Thank you @jaraco - I'll look over your boilerplate and see what I can glean from it. From this and other conversations I've had, it looks like the declarative approach is a safe (enough) and forward-thinking approach. Let's just, uh, pretend that I don't often have to pull Python dependencies from apt instead of pypi due to the lack of arm wheels (the legendary efforts of https://www.piwheels.org/ don't cover all versions).

Since I'm shipping almost exclusively for the Raspberry Pi I'm unlucky enough to have to deal with the exceptions and will no-doubt have to include a trap for old versions of setuptools. Still, the pyproject.toml approach appears useful- thank you.

Right now I'm uploading wheels, but not necessarily for all the Python versions that might appear on a Pi. I think I've got some learning to do with respect to the potential unversality of wheel files with and without binary extensions. I've spent a lot of time (about the last 5 years) just keeping up with shipping new libraries, and I'm keen to spend time adopting best practise and retrospectively improving those where and when I can.