Improve packaging by using PBR

[4383]

PBR (Python Build Reasonableness)[1].

Overview:

• remove python code
• introduce meta project configuration
• allow pypi to display readme at markdown format
• automatize semver management based on git tag name (example 1.0.0)
• automatize changelog generate
• automatize authors file generate

PBR allow to automatically manage your version bumping,
your changelog, your authors file and a lot of useful
features like this.

You just have to publish a git tag and pbr generate
a version number based on the git tag name (example: 1.0.0).

It also a good practice to use setup.cfg to centralize
project configuration:

• project meta
• wheel
• etc...

This commit remove python code to maintain by transform it
into configuration.

If you choose to distribute this project with pypi these
changes introduce readme displayed at markdown format compatible
with pypi.

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

Signed-off-by: Hervé Beraud [email protected]

[4383]

If you want to distribute this project over pypi I can easily help you since I already made these changes on several projects and introduce them to distribute over pypi by using CI jobs based on travis-ci and git tags.

You just have to push a new tag on github to trigger a new build and deploy a new version bumped on pypi based on git tag name.

Do you agree?

Thoughts?

[4383]

Introduce a CI pipeline can allow you to run tests with tox by example and to improve security/quality of this project.

[4383]

By trying to introduce unit test with tox locally I guess you need to split podman and pypodman into 2 separate projects.
It'll avoid cross dependencies between podman and pypodman. Currently tox try to managing dependencies and requirements from an non-existing project on pypi.

Another issue due to managing these both projects with only once repository is that you will deploy the both projects (podman, pypodman) on pypi due to git tag pushing only in one repository, it's not really an earthquake but you will increment your version number on both even if only one project was modified.... can disturb your users/maintainers...

[jwhonce]

@4383 I'm on board with changing the packaging. Having a CI push new code to pypi would be great. I have a podman project on the pypi testing servers. Eg.

# python3 -m pip install --index-url https://test.pypi.org/simple/ \
   --extra-index-url https://pypi.org/simple podman

I have been running tox locally and only on podman as that supports more use cases and platforms. Tying tox into the CI job for podman would be good.

For now, I would like to not publish pypodman to pypi so having it's version tied to the podman library doesn't seem to be too abusive. After we get the golang client out, we may resume this work and at that point we will be sure to review this. Or, if the community picks it up we can split the repositories.

[4383]

These changes doesn't tied up you to publish now on pypi.
To refactor packaging and introduce auto deployment on pypi we need:

1. introduce these changes
2. create a pypi account related to our team
3. bind this github repository with a travis-ci account (why travis? because it come with battery included and propose pypi deployment features)
4. introduce tox and trigger it on pipeline
5. push a git tag

I'm ok to help the community to maintain the pypodman part if needed but before split we need to be sure to stay synchronized between podman and pypodman by introducing specific tests to avoid regressions between API and client.

[rhatdan]

I am all for separating out pypodman from python3-podman. I care much more about the library then I do about the CLI. People use python3-docker for a ton of use cases, which we need to capture with python3-podman.

[jwhonce]

@4383 Do you have time to help move this forward?

[4383]

@jwhonce sure I can help you if needed. Just I'm on PTO during the next days so not available from tomorrow to Monday but after that I can share a part of my time with you.

[4383]

@jwhonce how do you want to proceed?
Do you have some plan?

[4383]

Ignore this one and prefer to use => #25