Open Stack

First, thanks a lot for your support and your kindness ! Really appreciate
that :)


> > Do you know where I need to hack PBR to fix it?
>
> So 'pbr' correctly parses the prefixed tags, but it's just the output
> packages (sdists, wheels) that always unversioned? If so, this sounds
> correct. Python packaging, as defined in PEP-440 [1], doesn't use the
> 'v' prefixes, so it doesn't really make sense to stick them in here.
> Out of curiosity, what's your rationale for modifying the package name?
>

The package name is not changed actually. With the patch in PBR that has
been merged, one could add a tag named "v1.0.0" on mypackage package,
and the sdist will generate a distribution package

mypackage-0.0.4.tar.gz


So I think (hope?) this is still PEP440 compliant.

I tried this feature on another software that also uses pbr and there is no
problem: v version works great with sdist/bdist/wheel packages.

I use it inside a Gitlab CE pipeline on a tag pipeline (CI is triggered when
a git tag that follows the "v*" regular expression), and instead of
creating
a package

mypackage-0.0.4-py2.py3-none-any.whl

it created

mypackage-0.0.3.dev3-py2.py3-none-any.whl.


When I retried manually on my development environment, pbr works
perfectly again on the same code.
I guess it somehow didn't used my build of the pbr package when
running in gitlab pipeline.

Do you plan on releasing PBR soon on pypi?
I have to build myself and push it on our internal nexus pypi, but I think
the
safest way is to wait for an official pbr release on pypi.python.org :)


> Second point, to go to the end of the logic of my change, I would
> > like to propose an optional way (in setup.cfg?) to **prevent** any
> > tag without the 'v' prefix, ie, where a bare version tag like `1.0.0`
> > is not to be considered as a valid version.
> > That way, on system such as gitlab or github:
> > - repository owners "protect" tags with pattern "v*", ie, all tags
> > for release such as "v1.0.0", ... cannot be pushed by anyone but the
> > owners/masters
> > - other developer can still push other tags for other purpose
>
> So this could be used to prevent pbr reading the tags, but it won't
> stop anyone from creating them in the first place (i.e. "protect"
> tags).


Yes, I agree this is not really mandatory. Gitlab tag protection should be
enough.

I am using a "protected environment variables" on gitlab, and indeed, the
credentials
to push on Pypi are only sent when the pipeline is triggered on such a
"protected"
branch or "protected tag".

So we "protect" only tags starting with a "v*" and only this triggered
pipeline
can publish to pypi (we use Nexus).

This allows other developers to add any tags not started with v (only
repository
owners can create tags starting with a "v*"). Note this "v*" regular
expression
is configurable and seem to default/good practice on GitLab CE/EE.


> We can do this but it would be a separate feature and, to be
> honest, I'd suggest using Git hooks or some form of access control as a
> better way to do this (Note: it seems GitLab already supports something
> similar [2]).
>

Yes this is what I actually use :) Thanks

In short: pbr v_version seems to work great, just hoping for the official
PBR
release on pypi.python.org :)

Thanks
Gaetan Semet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180115/ecd9c352/attachment.html>