Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141111/828fa443/attachment.html>