python-daemon

#23 Refactor packaging by introducing pbr.

Closed 5 years ago by bignose. Opened 5 years ago by hberaud.

hberaud/python-daemon refactor-packaging into master

Refactor packaging by introducing pbr.

Hervé Beraud • 5 years ago

ef319ec

README.rst ~~README~~

file renamed

file was moved with no change to the file

requirements.txt

file added

		`@@ -0,0 +1,1 @@`
		`+ lockfile>=0.10`

setup.cfg

file modified

+37 -7

		`@@ -1,5 +1,42 @@`
		`# setup.cfg`
		`# Python Distutils configuration options for this distribution.`
		`+ [metadata]`
		`+ name = python-daemon`
		`+ home-page = https://pagure.io/python-daemon/`
		`+ summary = Library to implement a well-behaved Unix daemon process`
		`+ description-file =`
		`+ README.rst`
		`+ author = Ben Finney`
		`+ author-email = ben+python@benfinney.id.au`
		`+ license = Apache License 2.0`
		`+ classifier =`
		`+ Development Status :: 5 - Production/Stable`
		`+ Intended Audience :: Developers`
		`+ License :: OSI Approved :: Apache Software License`
		`+ Operating System :: POSIX`
		`+ Programming Language :: Python`
bignose commented 5 years ago This project still needs to support Python 2. Can you ensure it works with the existing Python version declarations?
		`+ Programming Language :: Python :: 3`
		`+ Programming Language :: Python :: 3.5`
		`+ Programming Language :: Python :: 3.6`
		`+ Programming Language :: Python :: 3.7`
		`+ Topic :: Software Development :: Libraries :: Python Modules`
		`+ keywords =`
		`+ daemon`
		`+ fork`
		`+ unix`
		`+`
		`+ [files]`
		`+ packages =`
		`+ daemon`
		`+`
		`+ [extras]`
		`+ devel=`
		`+ pbr`
		`+ tox`
		`+`
		`+ [pbr]`
		`+ skip_authors = 1`
		`+ skip_changelog = 1`

		`[aliases]`
		`distribute = register sdist bdist_wheel upload`
		`@@ -13,10 +50,3 @@`

		`# Sign distributions, and upload the signing public key?`
		`sign = true`
		`-`
bignose commented 5 years ago Why are these lines removed? These (and similar blocks in other files) are useful “editor hints” for the Vim and Emacs text editors.
		`-`
		`- # Local variables:`
		`- # coding: utf-8`
		`- # mode: conf`
		`- # End:`
		`- # vim: fileencoding=utf-8 filetype=conf :`

setup.py

file modified

+6 -78

		`@@ -9,99 +9,27 @@`

		`""" Distribution setup for ‘python-daemon’ library. """`

		`- from __future__ import (absolute_import, unicode_literals)`
bignose commented 5 years ago Python 2.7 still requires this, if I understand this correctly. Have you tested whether this continues to work in Python 2?

		`import os.path`
		`- import pydoc`
		`- import sys`
		`import unittest`

		`- from setuptools import (setup, find_packages)`
		`+ from setuptools import setup`

		`- import version`
bignose commented 5 years ago This merge request removes references to the project version. How is this functionality preserved? Or is this a proposal to not use the Changelog as the source of the version string? If so I think we can't accept that.

		`-`
		`- fromlist_expects_type = str`
		`- if sys.version_info < (3, 0):`
		`- fromlist_expects_type = bytes`
		`-`
		`-`
		`- main_module_name = 'daemon'`
		`- main_module_fromlist = list(map(fromlist_expects_type, [`
		`- '_metadata']))`
		`- main_module = __import__(`
		`- main_module_name,`
		`- level=0, fromlist=main_module_fromlist)`
		`- metadata = main_module._metadata`
		`-`
		`- (synopsis, long_description) = pydoc.splitdoc(pydoc.getdoc(main_module))`
		`-`
		`-`
		`def test_suite():`
		`""" Make the test suite for this code base. """`
		`loader = unittest.TestLoader()`
		`suite = loader.discover(os.path.curdir, pattern='test_*.py')`
		`return suite`

		`-`
		`- setup_kwargs = dict(`
		`- distclass=version.ChangelogAwareDistribution,`
		`- name=metadata.distribution_name,`
		`- packages=find_packages(exclude=["test"]),`
		`- cmdclass={`
		`- "write_version_info": version.WriteVersionInfoCommand,`
		`- "egg_info": version.EggInfoCommand,`
		`- "build": version.BuildCommand,`
		`- },`
		`-`
		`- # Setuptools metadata.`
		`- zip_safe=False,`
		`- setup_requires=[`
		`- "docutils",`
		`- ],`
		`- test_suite="setup.test_suite",`
		`- tests_require=[`
		`- "unittest2 >=0.5.1",`
		`- "testtools",`
		`- "testscenarios >=0.4",`
		`- "mock >=1.3",`
		`- "docutils",`
		`- ],`
		`- install_requires=[`
		`- "setuptools",`
		`- "lockfile >=0.10",`
		`- ],`

		`- # PyPI metadata.`
		`- author=metadata.author_name,`
		`- author_email=metadata.author_email,`
		`- description=synopsis,`
		`- license=metadata.license,`
		`- keywords="daemon fork unix".split(),`
		`- url=metadata.url,`
		`- long_description=long_description,`
		`- classifiers=[`
		`- # Reference: <URL:https://pypi.org/classifiers/>`
		`- "Development Status :: 5 - Production/Stable",`
		`- "License :: OSI Approved :: Apache Software License",`
		`- "Operating System :: POSIX",`
		`- "Programming Language :: Python :: 2.7",`
		`- "Programming Language :: Python :: 3",`
		`- "Intended Audience :: Developers",`
		`- "Topic :: Software Development :: Libraries :: Python Modules",`
		`- ],`
		`- )`
		`+ setup(`
		`+ setup_requires=["pbr"],`
		`+ pbr=True,`
		`+ test_suite='setup.test_suite'`
		`+ )`

		`- # Docutils is only required for building, but Setuptools can't distinguish`
		`- # dependencies properly.`
		`- # See <URL:https://github.com/pypa/setuptools/issues/457>.`
		`- setup_kwargs['install_requires'].append("docutils")`

		`-`
		`- if __name__ == '__main__':`
bignose commented 5 years ago Please keep the actual `setup` call inside this block (by using the `setup_kwargs` dictionary). Using this condition allows importing this module, for unit tests among other things.
		`- setup(**setup_kwargs)`
		`-`
		`-`
		`# Copyright © 2008–2018 Ben Finney <ben+python@benfinney.id.au>`
		`#`
		`# This is free software: you may copy, modify, and/or distribute this work`

hberaud commented 5 years ago

Since python-daemon distribution facing issues
related to dependances management this commit
try to avoid this kind of problem and try to
simplify the project release management by using pbr.

This commit introduce:
- packaging metadata management by using configuration file;
- introduce PEP 516;
- introduce requirements file;
- convert README to rst format for a better visualization on pagure and better compatibility with pbr.

Using it:
- install pbr (pip install pbr);
- create a new tag (git tag 9.9.9) (by example...);
- build and dist (python setup.py build && python setup.py sdist);
- publish your release on pypi by using twine or whatever you want.

pbr[1] allow simplify python packaging by automatizing:
- semver[2] management;
- changelog generation;
- authors file generation.

[1] https://docs.openstack.org/pbr/latest/
[2] https://semver.org/

Co-authored-by: Hobbestigrou hobbestigrou@erakis.eu

hberaud commented 5 years ago

Please be careful to merge these pull requests in order:

Thank you

Edited 5 years ago by hberaud

bignose commented on line 48 of setup.cfg 5 years ago

Why are these lines removed? These (and similar blocks in other files) are useful “editor hints” for the Vim and Emacs text editors.

bignose commented on line 100 of setup.py 5 years ago

Please keep the actual setup call inside this block (by using the setup_kwargs dictionary). Using this condition allows importing this module, for unit tests among other things.

bignose commented on line 5 of setup.py 5 years ago

Python 2.7 still requires this, if I understand this correctly. Have you tested whether this continues to work in Python 2?

bignose commented on line 18 of setup.cfg 5 years ago

This project still needs to support Python 2. Can you ensure it works with the existing Python version declarations?

bignose commented on line 15 of setup.py 5 years ago

This merge request removes references to the project version. How is this functionality preserved?

Or is this a proposal to not use the Changelog as the source of the version string? If so I think we can't accept that.

hberaud commented 5 years ago

Current project version are determined by using git tag. If you want to bump your version number you just have to create a new git tag where the name correspond to your version number bumped.

bignose commented 5 years ago

If you want to bump your version number you just have to create a new git tag […]

Thanks for explaining. So, if I understand correctly, that is in addition to the existing need to track the version string in the changelog document.

So I think this merge request makes a lot of changes by moving functionality around; and it removes some useful features already implemented; and it adds double handling to the development workflow.

Is that right? I think it is not much advantage to merge these changes.

hberaud commented 5 years ago

This pull request simplify and reduce your code.

PBR and setptools bring together lot of functionalities who avoid to you to maintain our own changelog generator, version manager etc...

You can be focused on the development of your daemon instead of deal with packaging issues etc...

No double handling. You just have to create a git tag and that's all. On the contrary, it saves your time by removing manually actions on your side.

Do you need more informations?

Thoughts?

bignose commented 5 years ago

No double handling. You just have to create a git tag and that's all.

That is in addition to writing a changelog entry for each version. So yes, it's double handling.

Note that a changelog document needs to be written anyway and should not be automatically generated. So that's the primary location of a version string, and the date of the release.

I don't think there's a good reason to introduce the double handling. Until PBR can read the canonical version information from the changelog, I won't alter the development workflow to multiply the places where this information is stored.

Thank you for the work, but I will reject this merge request.

Edited 5 years ago by bignose