[openstack-dev] [oslo] pbr refactor

Robert Collins robertc at robertcollins.net
Tue Nov 11 23:09:24 UTC 2014

Hi, I have one patch pending, so the tests for the version calculation
and the version.py module itself are all that you need to care for, to
avoid conflicts.


On 12 November 2014 11:54, Kenny Jones <kenny.jones at gmail.com> wrote:
> I have submitted the first patch which focuses on the initial refactor of
> pbr.packaging module.
> https://review.openstack.org/#/c/133607/
> With that change I have created the following modules:
> pbr
>     common
>     git
>     requirements
>     cmds (package)
>         build_doc
>         egg_info
>         install
>         install_scripts
>         sdist
>         test
> The commands module are meant to mimic what is done by setup_tools and
> distribute.
> All the git commands are moved into git module, requirements processing is
> moved into the requirements module, and the handful of truly common
> functions are placed within common.
> All references to packaging module within pbr (except version) have been
> replaced by the new module. All tests have been updated to test the new
> modules.
> I have a second set of changes prepared and tested, and will submit those
> after the above patch is merged that will focus on refactor of the version
> module. The details can be found below, but based on Doug's feedback I'm
> holding that patch to avoid conflict with Robert's SemanticVersion work
> unless Robert thinks it could accelerate his work by having the code base
> refactored.
> Any and all feedback welcome, and input on timing of the second patch.
> Thanks
> Kenny
> ---------- Forwarded message ----------
> From: Doug Hellmann <doug.hellmann at gmail.com>
> Date: Sat, Oct 25, 2014 at 3:23 PM
> Subject: Re: pbr refactor
> To: Kenny Jones <kenny.jones at gmail.com>
> Cc: Mark McLoughlin <markmc at redhat.com>
> Hi, Kenny,
> Sorry for the delay in replying; summit prep is taking a lot of my time
> right now.
> It sounds like you’ve done a lot of cleanup on the pbr code. I haven’t had a
> chance to look at the actual changes you’ve made, but I’ve tried to leave
> some general comments below.
> On Oct 21, 2014, at 12:50 AM, Kenny Jones <kenny.jones at gmail.com> wrote:
> Hi Doug and Mark,
> I've become a big fan of pbr for the past year. I wanted to add some
> features but after really going through all the code as well as the base
> setuptools and distribute libraries it seemed to be that pbr needed some
> refactoring to make it easier to support and manage.
> I forked the repository on github, and applied changes through 3 separate
> branches to keep the amount of changes smaller.
> https://github.com/shad7/pbr
> feature/packaging_refactor
> The focus of this branch was to refactor the packaging module which was
> doing so many different tasks that it seemed like the most logical starting
> place.
> I refactored the module into:
> common - the couple of utility functions that were used in several modules
> git - all the git related functions
> requirements - all the requirements processing functions
> package cmds - each command broken up into separate module similar to how
> setuptools and distribute are setup.
> The divisions you list make sense.
> feature/version_refactor
> The focus of this branch was refactor all the logic related to versioning.
> Some logic was previously within packaging, some within version module, then
> referenced in others. I broke up the logic
> into a package pkgversion (wanted to avoid conflict with module version and
> provide some backwards compatiability).
> __init__ is what the original version module had prior to semantic class
> being introduced
> semantic is the new semantic class
> metadata is the logic previously located with packaging, some pieces within
> Semantic and others within VersionInfo.
> I then updated the version module to reference the
> pbr.pkgversion.VersionInfo so that any team making direct use of the class
> would not be directly impacted.
> This change should also help with potentially separating all version logic
> into oslo.version, and leave packaging to pbr. But that is for future
> changes.
> Robert has some SemVer work planned or ongoing, so this might disrupt those
> patches. We may want to wait to take this set of changes until his patches
> are merged, to avoid extra rebases for either of you.
> feature/upload
> Small extension to support the upload command as separate from the packaging
> native to setuptools. The idea came from twine, but just extended the
> existing setuptools upload by providing lookup of the already built
> distribution archives such that upload would work separate from packaging.
> We have talked once or twice about disabling upload entirely and encouraging
> the use of twine, which handles secure uploads properly.
> All test cases work as before. Added some additional test cases I had
> written previously for requirements testing. And was able to verify it
> passed all pep8/hacking standards, and tested for all the configured
> versions of python.
> What I'm looking for is, are these changes of interest to the team, and what
> would be the best strategy for submitting them. I am familiar with
> submitting patches as I've gone through it previously with a minor change
> (requirements parsing). But due to delays in getting approval, other changes
> kept coming along that caused conflicts such that it never made it all the
> way to merge into master. Given the size of my changes, I thought it was
> best to reach out and determine interest and approach for successfully
> submitting and merging.
> The best thing is probably for you to submit patches for the changes, except
> I think the upload command since we favor using twine over direct uploads. I
> can’t promise fast reviews this cycle, since most of the team is going to be
> focused on continuing to graduate code from the incubator, but it sounds
> like most of what you have to propose is not very controversial. Keep in
> mind that the summit is coming up next week, so it will be some time before
> any of us are reviewing much code at all.
> Thanks,
> Doug
> Any feedback and thoughts appreciated.
> Thanks
> Kenny
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the OpenStack-dev mailing list