add license file, setuptools dependency

[bollwyvl]

Hello! Thanks for the work!

Background: I'm working on packaging stopit for conda over on conda-forge:
conda-forge/staged-recipes#4708

If you'd like, I can add you as a maintainer there as well!

Anyhow, as part of that, here's a small PR which:

• adds a LICENSE file (based on this template)
• includes the license and the tests in the distribution
• adds the dependency on setuptools to setup.py

Thanks again!

[jakirkham]

Why is this needed?

[bollwyvl]

Unless i'm mistaken, pkgresources is provided only by setuptools?
https://github.com/glenfant/stopit/blob/master/src/stopit/__init__.py#L10

[glenfant]

That's OK for me but IMHO if tou have pip, you already have setuptools. That's why I didn't add it to setup.py. Unless you nee it for conda packaging.

[jakirkham]

Correct @bollwyvl. Wasn't sure if pkg_resources was involved hence the question. Agree that it should be added.

[webknjaz]

It shouldn't be added, in some cases setuptools depending on itself caused failures for me while using pip install -U, also this code is already being executed by setuptools (hence from setuptools import setup), if there's no setuptools prerequisite it will fail on import earlier (given dist dist being installed from sdist).
P.S. in some ancient envs pkg_resources has been provided as a separate dist.

[graingert]

100% never depend on setuptools

[glenfant]

Hi @bollwyvl , and thanks to help improving stopit. Two comments:

• I'm considering to switch the license to MIT that's more liberal (include stopit in whatever distro you want)

• I intentionnally didn't include the tests and doc in the distro (the wheel or tar.gz) to keep this package as light as possible. So please don't do this.

[bollwyvl]

Howdy! Just suggestions, feel free to close this or do with it what you will! If you do keep GPL, definitely add it to your repo, and consider including the license in the distribution, as per the license :P

Yeah, it's possible to not have pip, i guess, and then also possible not to have setuptools. I imagine a virtualenv without pip is possible, too. So kinda pseudo standard lib, and not usually used in this way, from what i've seen.. not sure which PEP would cover that...

[bollwyvl]

Yeah, as i mentioned, i've usually seen the canonical version info stored with the source (i.e. _version.py, in __init__.py), and read into setup.py, which obviates the need for runtime pkg_resources. while runtime inspection of the distributions can be useful for extensibility, it might be overkill here... anyhow, PUG says: https://github.com/pypa/python-packaging-user-guide/blob/0dcf950850644900af322343fc32025ad8994207/source/single_source_version.rst It doesn't really suggest which is best, though the pkg_resources does have a "be aware" but not a "warning".

…

On Tue, Jan 2, 2018 at 1:53 PM jakirkham ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In setup.py <#15 (comment)>: > @@ -47,5 +47,7 @@ def read(*names): packages=find_packages('src'), package_dir = {'': 'src'}, test_suite='tests.suite', + install_requires=['setuptools'], Correct @bollwyvl <https://github.com/bollwyvl>. Wasn't sure if pkg_resources was involved hence the question. Agree that it should be added. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACxRDqwdtDT2xy7C1uWbW9bnJw1eiAXks5tGnsrgaJpZM4RNlG7> .

[colin-nolan]

@glenfant it would be useful if the license could be changed to MIT - GPL is rather restrictive for a small library like this.

[glenfant]

Created the 1.1.2 with license set to MIT, tested with Python 3.5 and Python 3.6.

[bollwyvl]

Great, we've packaged up the new MIT-licensed one:
https://anaconda.org/conda-forge/stopit/files?version=1.1.2

Would still love to see the LICENSE included in the distribution!

[glenfant]

@bollwyvl The MIT license file is in the repo. Is it usual to have it in the source / wheel distro ?

[bollwyvl]

tl; dr: no, including the license text isn't universal on pypi, or even in many conda packages. Other package management ecosystems, like debian, have it as a hard requirement. In conda-forge, we're trying to get more in line, as the idea is to make free/libre software as usable as possible, both from the technical angle, i.e. "my python works with my R works with my tensorflow" as well as "not going to freak out my boss or legal team" angle. So as we go along, when we package for conda-forge, we include the license directly, as you intend it to be honored, an usually try to make an upstream request to make the process more predictable in the future.

• IANAL
• this hasn't been tested, to my knowledge, in court..
• and not to get too on it, BUT

a software license is a legal document. Right in the terms of all of them is usually a clause that says, something like, as in MIT:

The above copyright notice and this permission notice shall be included in all 
copies or substantial portions of the Software.

Each download of the package constitutes a copy. So if a package doesn't distribute its license, that copy isn't technically in compliance with the license of the source repo, and one could imagine some lawyers using that in case they were infringing your license (pretty hard, actually with MIT)... but you really don't want to run afoul of the SHOUTING at the bottom, which covers you in case the software is faulty and causes harm.

IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE 
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY

this is the kind of thing where you end up with "100,000 cases of infringement" or whatever.
So anyhow, MIT is 1kb in the wheel, and will keep both the lawyers and the neckbeards away. Win! If you don't include it in a future release, we'll continue to include it for you in the conda package! Thanks again!

[bollwyvl]

Oh, and this is a great read:
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html

[webknjaz]

This also needs to be added to setup.cfg as license_file in [metadata] section for the sake of wheels.