<div dir="ltr">I have submitted the first patch which focuses on the initial refactor of pbr.packaging module.<div><br></div><div><a href="https://review.openstack.org/#/c/133607/">https://review.openstack.org/#/c/133607/</a></div><div><br></div><div>With that change I have created the following modules:</div><div><br></div><div>pbr</div><div> common</div><div> git</div><div> requirements</div><div> cmds (package)</div><div> build_doc</div><div> egg_info</div><div> install</div><div> install_scripts</div><div> sdist</div><div> test</div><div><br></div><div>The commands module are meant to mimic what is done by setup_tools and distribute.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Any and all feedback welcome, and input on timing of the second patch.</div><div><br></div><div>Thanks</div><div>Kenny</div><div><br></div><div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Doug Hellmann</b> <span dir="ltr"><<a href="mailto:doug.hellmann@gmail.com">doug.hellmann@gmail.com</a>></span><br>Date: Sat, Oct 25, 2014 at 3:23 PM<br>Subject: Re: pbr refactor<br>To: Kenny Jones <<a href="mailto:kenny.jones@gmail.com">kenny.jones@gmail.com</a>><br>Cc: Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br><br><br><div style="word-wrap:break-word">Hi, Kenny,<div><br></div><div>Sorry for the delay in replying; summit prep is taking a lot of my time right now.</div><div><br></div><div>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.</div><div><br><div><span class=""><div>On Oct 21, 2014, at 12:50 AM, Kenny Jones <<a href="mailto:kenny.jones@gmail.com" target="_blank">kenny.jones@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Doug and Mark,<br><br></div>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.<br><br></div>I forked the repository on github, and applied changes through 3 separate branches to keep the amount of changes smaller.<br><br><a href="https://github.com/shad7/pbr" target="_blank">https://github.com/shad7/pbr</a><br><br>feature/packaging_refactor<br></div>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.<br></div>I refactored the module into: <br>common - the couple of utility functions that were used in several modules<br>git - all the git related functions<br>requirements - all the requirements processing functions<br>package cmds - each command broken up into separate module similar to how setuptools and distribute are setup.<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div></span><div>The divisions you list make sense.</div><span class=""><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><br></div>feature/version_refactor<br></div>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<br></div>into a package pkgversion (wanted to avoid conflict with module version and provide some backwards compatiability).<br></div>__init__ is what the original version module had prior to semantic class being introduced<br></div>semantic is the new semantic class<br>metadata is the logic previously located with packaging, some pieces within Semantic and others within VersionInfo.<br></div>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.<br></div>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.<br></div></div></div></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><br></div>feature/upload<br></div>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.<br></div></div></div></div></div></blockquote><div><br></div></span><div>We have talked once or twice about disabling upload entirely and encouraging the use of twine, which handles secure uploads properly.</div><span class=""><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><br></div>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.<br><br></div>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.<br></div></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>Thanks,</div><div>Doug</div><span class=""><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div><br></div>Any feedback and thoughts appreciated.<br><br></div>Thanks<br>Kenny<br><br></div>
</blockquote></span></div><br></div></div></div><br></div></div>