#23 Refactor packaging by introducing pbr.
Closed 2 years ago by bignose. Opened 2 years ago by hberaud.
hberaud/python-daemon refactor-packaging  into  master

README.rst README
file renamed
file was moved with no change to the file
file added
+1
@@ -0,0 +1,1 @@ 

+ lockfile>=0.10

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

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

- 

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 :

file modified
+6 -78
@@ -9,99 +9,27 @@ 

  

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

  

- from __future__ import (absolute_import, unicode_literals)

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

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__':

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

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

Please be careful to merge these pull requests in order:

  1. 23

  2. 24

  3. 25

  4. 26

Thank you

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

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.

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

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

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.

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.

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.

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?

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.

Pull-Request has been closed by bignose

2 years ago