Merge lp:~broder/ubuntu-dev-tools/fix-785854 into lp:~ubuntu-dev/ubuntu-dev-tools/trunk
Proposed by
Evan Broder
Status: | Superseded |
---|---|
Proposed branch: | lp:~broder/ubuntu-dev-tools/fix-785854 |
Merge into: | lp:~ubuntu-dev/ubuntu-dev-tools/trunk |
Diff against target: |
486 lines (+147/-19) (has conflicts) 21 files modified
404main (+2/-1) ack-sync (+1/-1) backportpackage (+1/-1) debian/changelog (+11/-0) dgetlp (+2/-1) get-branches (+1/-1) import-bug-from-debian (+1/-1) lp-project-upload (+2/-1) pbuilder-dist (+1/-1) syncpackage (+1/-1) ubuntu-iso (+2/-1) ubuntutools/archive.py (+1/-1) ubuntutools/builder.py (+1/-1) ubuntutools/misc.py (+1/-1) ubuntutools/requestsync/common.py (+2/-1) ubuntutools/requestsync/mail.py (+1/-1) ubuntutools/sponsor_patch/patch.py (+2/-1) ubuntutools/sponsor_patch/sponsor_patch.py (+1/-1) ubuntutools/subprocess.py (+109/-0) ubuntutools/test/test_help.py (+1/-1) ubuntutools/test/test_pylint.py (+3/-1) Text conflict in debian/changelog |
To merge this branch: | bzr merge lp:~broder/ubuntu-dev-tools/fix-785854 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Barry Warsaw (community) | Needs Fixing | ||
Review via email: mp+62180@code.launchpad.net |
This proposal has been superseded by a proposal from 2011-06-19.
To post a comment you must log in.
Hi Evan,
I totally see why you've added this, and changed the code to use it. Thanks for making ubuntu-dev-tools better! Of course, once we migrate u-d-t to Python 3.2 this change won't be necessary <wink>.
I'm a little concerned that what you've written isn't entirely API compatible with Python's version. Python's subprocess.Popen is a class while ubuntutools. subprocess. Popen is a function. I have no idea whether people actually try to subclass subprocess.Popen, and within u-d-t it's easy enough to guarantee this, but is it possible there are would be external clients that could be broken by this? It makes me uncomfortable that your docs claim API compatibility when it's really not.
Two thoughts: could this be implemented as a subprocess.Popen subclass?
Or, would it make sense to just use a different API rather than promoting something that looks like stdlib subprocess.Popen but isn't quite? The way you have it does mean that existing code in u-d-t doesn't have to change, except for the import statement. I'm not sure whether that's good or not ;).
You might also call inspect. getargspec( ) at module scope and then not redefine, but simply expose the stdlib subprocess functions directly in ubuntutools. subprocess. Popen.
Anyway, just some thoughts. At the least, please do indicate in the docs about this difference. I'm happy to chat about alternatives in IRC if you want.