Skip to content
This repository was archived by the owner on Feb 10, 2021. It is now read-only.

Improve packaging by using PBR #20

Closed
wants to merge 1 commit into from

Conversation

4383
Copy link
Collaborator

@4383 4383 commented Feb 12, 2019

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]

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
Copy link
Collaborator Author

4383 commented Feb 12, 2019

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
Copy link
Collaborator Author

4383 commented Feb 12, 2019

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

@4383
Copy link
Collaborator Author

4383 commented Feb 12, 2019

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
Copy link
Member

jwhonce commented Feb 12, 2019

@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
Copy link
Collaborator Author

4383 commented Feb 12, 2019

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
Copy link
Member

rhatdan commented Feb 13, 2019

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
Copy link
Member

jwhonce commented Mar 5, 2019

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

@4383
Copy link
Collaborator Author

4383 commented Mar 6, 2019

@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
Copy link
Collaborator Author

4383 commented Mar 6, 2019

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

@4383
Copy link
Collaborator Author

4383 commented Mar 28, 2019

Ignore this one and prefer to use => #25

@4383 4383 closed this Mar 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants