Missing package version

[athos-ribeiro]

Now that the package is no longer under the libpod repository, should it be versioned independently?

If so, one should have in mind that the last release on pypi was 0.11.1.1 (it would also be nice to Tag this repository in the revision that originated the pypi release).

This issue may also be related to #25

[h-vetinari]

@jwhonce
I want to package python-podman for conda-forge; it would be good to have a version to tag (instead of a git-commit).

[h-vetinari]

@jwhonce @rhatdan
How far do you think you are away from a versioned release? Anything left to do that needs help?

I want to switch an existing application to podman for several reasons, and part of that is a flask-app that would then have to talk to podman instead of docker. Since I need podman>=1.3, the existing package on pypi is not an option.

[rhatdan]

I'm willing to cut a version at any time.

[rhatdan]

@jwhonce could you cut the initial version.

[4383]

@athos-ribeiro pypi deployments are currently stucked, we plan to releases python-podman versions related to libpod versions, but before that we need to address the deployment issue which is related to:

• Fail uploads with an invalid description pypi/warehouse#5835
• HTTPError: 400 Client Error: The description failed to render in the default format of reStructuredText pypi/warehouse#5890

FYI the pypa team have reintroduce some checks on package deployment and especially long_description format type (markdown, restructuredText) and syntaxe checks to avoid to generate pypi project pages description in a raw format when something went wrong.

I think the main idea behind the test reintroduced by the pypa team is to block deployment of projects releases where the syntaxe description is wrong and where parsers can't generate a proper description for projects pages, so they choose to block deployments to force users to fix syntaxe issue on project side instead of generate description page in a raw format, they changes make sense and can help to obtain a more proper pypi/warehouse.

We need to specify the format that we use by using long_description_content_type = text/markdown and my PR will reintroduce this config.

In a second time we have another issue always with description format where on CI twine check dist/* fail to detect the markdown format that we reintroduce with my changes, and locally I can't reproduce the issue... locally the same code work fine...

So for the moment we looking for understand why things fails with the help of some pypa guys.

I hope these informations can be useful for you.

[athos-ribeiro]

Thanks for the thorough description, @4383

PS: the pypi stuck deployments URL is pointing to this issue

[4383]

Thanks for the thorough description, @4383

PS: the pypi stuck deployments URL is pointing to this issue

Oh thanks @athos-ribeiro , I wanted to speak about this one => #37

[4383]

@rhatdan @jwhonce now that #37 is merged can we try to push a new git tag 0.0.3 to github and deploy it on pypi?

Just one thing, take care to don't prefix the tag name with the letter v please, like v0.0.1 and v0.0.2.
The letter v is useless.

Anyway it's not an issue for pbr.

pbr can manage format like v0.0.1, but it's not really useful to keep it.

After that if everything works well we can deploy a real version related to the libpod version to close this issue.

[rhatdan]

How do we set the version, when I install what is in master I see.
build/lib/podman/init.py: version = '0.0.0'

[4383]

@rhatdan you don't have to set the version. The version is managed by using git tag so if you create a new git tag 0.0.3 and upload it to github then podman will be built and deployed to pypi in version 0.0.3.

The version that you see is an oldest code introduced before pbr and the latest changes related to pypi deployment..

I will publish a merge request to remove this outdated code.

I hope my explaination as clear, don't hesitate to ask if needed.

[rhatdan]

Ok, thanks.