Don't include license file as part of the package

[EpicWink]

Including the license file LICENSE.md as part of the package data meant that the file was installed into the user's package directory 'site-packages/'. Declaring the file in MANIFEST.in keeps the license file as part of the source-distribution, and the built-distribution (wheel) automatically finds license files already.

[rr-]

Is there a way to avoid having a myriad of files? I'd like to avoid adding yet another metadata file just for some legal shenanigans. Also what does @lachs0r think who was the original issue reporter

[EpicWink]

You can drop MANIFEST.in and all but two lines of setup.py by specifying all of the installation configuration in setup.cfg: see the setuptools docs for more information

Your setup.py becomes:

from setuptools import setup
setup()

Included in the setup.cfg is an entry "license_file", where you specify the license file path, so no more need for MANIFEST.in. See my setup.cfg for an example

Edit: I should also mention, you are obliged by the license to include the notice in the distribution (ie what you give to everyone else). Whether they keep it with the installed code would really be up to them, even if it's PIP that drops the file. Disclaimer: I'm not a lawyer

Edit 2: You can use setuptools-scm to include all tracked files to the source-distribution

[rr-]

Is there any way to consolidate setup.cfg with pyproject.toml? Would you recommend setup.cfg+simple setup.py over complex setup.py?

[EpicWink]

pyproject.toml isn't currently well documented enough for it to be recommended to replace setup.py or setup.cfg yet, but I'll have a look at PIP's code to see what it supports (I suspect it accepts the same format as setup.cfg)

I imagine most would advise having declarative (setup.cfg, project.toml) over imperative (setup.py) configuration, as for one thing there's less code to maintain and it's more readable, and for another configuration should be simple and repeatable, which outsourcing the code implicitly ensures (hopefully)

[EpicWink]

After some investigation, it seems setuptools (which PIP defaults to) doesn't support pyproject.toml as a replacement for setup.py or setup.cfg yet. The metadata can't be defined in pyproject.toml, and setuptools still calls setup.py to build project metadata.

All of my company's projects have moved to only having the setup call with no arguments in setup.py with metadata and config defined in setup.cfg (except for compiled packages, where the C modules still need to be configured in setup.py). My colleagues prefer the simpler design of setup.cfg

[rr-]

Thanks for your investigation. That's unfortunate. I'll convert it to setup.cfg then!

[rr-]

I've pushed relevant change on master, lmk if it's good :–]

[EpicWink]

I've pushed relevant change on master, lmk if it's good :–]

Wasn't quite a one-to-one conversion; see #15

[rr-]

Done, should be better now?

[EpicWink]

@rr- Further information: pypa/setuptools#1675 means pip now can install packages without a "setup.py", as long as the setuptools.build_meta build-backend is used (declared in "pyproject.toml", in table build-system).

People with older versions of pip (Ubuntu 18.04 users, for example) won't have this functionality however, so you may want to keep the "setup.py" for now

pypa/setuptools#1688 is the discussion thread on including setuptools config in "pyproject.toml"