setuptools doesn't install licenses

[ghost]

Originally reported by: notting (Bitbucket: notting, GitHub: notting)

---

1. Most python software is licensed under MIT, BSD, or similar licenses
2. These licenses require shipping a copy of the license with distributions of the software.

Ergo, setuptools should add the LICENSE or COPYING file to the egginfo/distinfo directory by default, so licenses get distributed automatically.

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/357

[jakirkham]

Would it be possible to have a license_file keyword argument for setup? This file (or directory or list if multiple) could then just get copied over.

[agronholm]

The license file already comes included in the sdist (barring any mishaps by the author). As for wheels, you can add license_file = LICENSE option in the [metadata] section in setup.cfg. This feature has not been documented but I will rectify that once I overhaul wheel's documentation.

[anntzer]

It appears that unless the license file is explicitly mentioned in the manifest, it will NOT be included (just tested with setuptools 36.5.0 / distutils from Py 3.6). This is also the behavior documented in https://docs.python.org/3.6/distutils/sourcedist.html#specifying-the-files-to-distribute.

But as you point out yourself, it is easy enough for setuptools to find that information: it should read it from setup.cfg's metadata.license_file, to avoid having to duplicate it.

[pganssle]

I think this is a reasonable enhancement. The new behavior should be that python setup.py sdist should include the license file if license_file is included in setup.cfg unless it is explicitly excluded in MANIFEST.in.

There's a case to be made for including anything called LICENSE or LICENSE.txt or LICENSE.md by default, as well, but I think that needs further discussion.

[dtaneli]

Working on this as part of PyPA Sprint Weekend at Bloomberg (2018)

[EvgenKo423]

I want to note that the license files only get included in a source distribution, but they are NOT installed with the package! On the other hand, when you build a wheel the license files are copied into the .dist-info folder AND get installed with the package as well. It also looks like the behavior originally requested in this issue, as the license files should be distributed with every copy of the software.

[pganssle]

@EvgenKo423 Installation via setup.py install is not, as far as I know, supported. You should build a wheel and install that, or use a front-end that does it for you, in which case the problem is solved, no?

[EvgenKo423]

No. Many packages on PyPI only provide a source distribution. I've tried building a source distribution of my own package with a license_files option and installing it via pip install -U path\to\sdist.tar.gz and the license file was just dropped with the rest of the sources after installation.

It's clearly not a pip's job to deal with installation details, it just calls the setup.py install command you mentioned in a bizarre way.

[jakirkham]

It's possible to build a wheel from a sdist. Setuptools will package licenses in the sdist as long as the package author listed them in their setup.py or setup.cfg

[pganssle]

@EvgenKo423 At this point the way it works in pip (and the supported workflow) is source (sdist, repo) → wheel → installation.

setuptools (or any other PEP 517 back-end) is responsible for the source → wheel portion and pip (or any other PEP 517 front-end) is responsible for the wheel → installation portion. If setuptools builds a wheel that contains a license file in such a way that PEP 517 front-ends don't include the license and you think that it should include the license, then that is a problem (and a separate issue to be raised). If the problem only occurs when you run setup.py install, then following the official guidance of "do not invoke setup.py install directly", there will be no problem.

Hope that clears up the confusion. I recognize that invoking setup.py has been the official guidance for a long time, but we've also been actively discouraging people from using setup.py install for at least as long as I've been involved in the project (3-4 years), and have not actively supported it for at least that long. I realize this comes as a surprise for many people, and the reason we haven't been raising big loud warnings about this is that the advice is a bit more nuanced than that and at the moment it's difficult to 1. differentiate between valid and invalid uses of setup.py install and 2. communicate to users exactly what they should do in each situation. If there were more resources devoted to this project we could likely make progress more rapidly on the blockers for these issues, but as it is doing so is difficult and things mostly work and people's workflows are mostly evolving towards doing the right thing anyway, so 🤷.

[jaraco]

I've tried building a source distribution of my own package with a license_files option and installing it via pip install -U path\to\sdist.tar.gz and the license file was just dropped with the rest of the sources after installation.

I was unable to reproduce this behavior. To confirm, when installing a package from source using pip, the license file does get installed:

draft $ pip download --no-binary setuptools setuptools
Collecting setuptools
  Downloading setuptools-54.0.0.tar.gz (2.1 MB)
     |████████████████████████████████| 2.1 MB 1.8 MB/s 
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Saved ./setuptools-54.0.0.tar.gz
Successfully downloaded setuptools
draft $ pip-run -q ./setuptools-54.0.0.tar.gz -- -c "import importlib.metadata as md; print(md.distribution('setuptools').read_text('LICENSE')[:10])"
Copyright 

[jakirkham]

@EvgenKo423 are you able to share a minimal reproducer? That might help point out what issues are being encountered and also help people here to provide more relevant advice for your use case 🙂

[EvgenKo423]

It all falls down to pip.
It only happens for setup.py-style sources without wheel installed. It should be happening with pyproject.toml without build-backend as per PEP 517, but the legacy build process is never invoked and I'm not sure if it's worth fixing as it has been there since at least pip==19.1.1 and would cause the issue I'm talking about for more people.

---

Installation via setup.py install is not, as far as I know, supported. You should build a wheel and install that, or use a front-end that does it for you, in which case the problem is solved, no?

Many users don't have your knowledge, I guess (but thanks for mentioning PEP 517).
pypa/pip#7709 and pypa/pip#8102 are the warnings you at PyPA were looking for, but it would be cool to have them since those were implemented in a first place, for those who are "in a tank".
If people have an existing Python install and just update the packages they will have no idea.

I currently have a pip==19.1.1, setuptools==43 @ Python 3.4 (don't ask why) and at this point the way it works for me is pip calling setup.py install and no mention of wheels whatsoever...