pip-licenses can't find license for txtorcon
meejah opened this issue · 9 comments
Is something funky with how this is packaged or something? pip-licenses says the license for latest txtorcon is unknown (seems to be correctly tagged as "MIT" though)
@meejah Hi, I am the author of pip-licenses.
Your package seems to be missing license or classifiers as meta information registered in PyPI.
For example, the API returns such a result.
https://pypi.org/pypi/txtorcon/json
pip-licenses reads meta information and outputs license information.
So It read such meta information and output it as "MIT".
https://pypi.org/pypi/pip-licenses/json
I recommend that you try to check the upload flow to your PyPI.
Hi, great thanks for the reply!
As far as I can tell, setup.py has license='MIT' in it and some classifier that mentions MIT. I use Twine to upload, as here: https://github.com/meejah/txtorcon/blob/master/Makefile#L121
I cloned this repository locally and tried python setup.py bdist_wheel --universal.
License information is recorded in the generated txtorcon-19.0.0.dist-info/METADATA file. Your setup.py is valid.
Metadata-Version: 2.1
Name: txtorcon
Version: 19.0.0
Summary: Twisted-based Tor controller client, with state-tracking and
configuration abstractions.
https://txtorcon.readthedocs.org
https://github.com/meejah/txtorcon
Requires-Dist: Twisted[tls] (>=15.5.0)
Requires-Dist: zope.interface (>=3.6.1)
Requires-Dist: incremental
Requires-Dist: automat
Requires-Dist: ipaddress (>=1.0.16) ; python_version < "3"
Provides-Extra: dev
Requires-Dist: tox ; extra == 'dev'
Requires-Dist: coverage ; extra == 'dev'
Requires-Dist: cuvner ; extra == 'dev'
Requires-Dist: setuptools (>=0.8.0) ; extra == 'dev'
Requires-Dist: Sphinx ; extra == 'dev'
Requires-Dist: repoze.sphinx.autointerface (>=0.4) ; extra == 'dev'
Requires-Dist: coveralls ; extra == 'dev'
Requires-Dist: codecov ; extra == 'dev'
Requires-Dist: wheel ; extra == 'dev'
Requires-Dist: twine ; extra == 'dev'
Requires-Dist: pyflakes ; extra == 'dev'
Requires-Dist: pycodestyle ; extra == 'dev'
Requires-Dist: mock ; extra == 'dev'
Requires-Dist: ipaddress (>=1.0.16) ; extra == 'dev'
Requires-Dist: geoip ; extra == 'dev'
Requires-Dist: readme-renderer ; extra == 'dev'
Home-page: https://github.com/meejah/txtorcon
Author: meejah
Author-email: meejah@meejah.ca
License: MIT
Classifier: Framework :: Twisted
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: MIT License
Classifier: Natural Language :: English
Classifier: Operating System :: POSIX :: Linux
Classifier: Operating System :: Unix
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.6
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Classifier: Topic :: Internet :: Proxy Servers
Classifier: Topic :: Internet
Classifier: Topic :: Security
Is not the information broken in the workflow before and after executing make release?
For example, in txtorcon 0.14.0 metadata has been uploaded.
But in the latest release metadata is missing.
The project description generated from README.rst also seems broken in pypi.org Web UI.
Hrrmmm. The only change I see in the Makefile from 0.14.0 is basically "adding python3 support" to the wheels. I don't know what version of twine uploaded 0.14.0 vs. latest release, though. Is it possible that's the problem? (I don't like using python setup.py upload ...) There were some changes to metadata "stuff" in setup.py from that version to now, but if the .whl-building works as it's stated in the current Makefile, that shouldn't be the issue, right?
Thanks for the help!
Also as for the README rendering, I don't know what's wrong -- jobs for the tox environment readme_render are supposed to show whether it's broken or not (says master is working): https://www.travis-ci.org/meejah/txtorcon/jobs/504380183
Ahhh, it seems if you use twine check .....tar.gz or so, it find problems. So, that should go into the workflow and the readme_render tox environment...
Weird: it seems the twine check command rejects any titles in the README (at least, if you're using rst)
Apparently the line-numbers are meaningless in twine check. I have also tried to get markdown to work instead, but it seems like triple-backtick code-block quoting doesn't work? ("or something" because I'm mostly-guessing because the line numbers seem way off)
Okay, latest release works with pip-licesnses again