Hello! I wrote a branch [1] to implement what I thought the results
of past discussions was (see "Project root refactoring" and "Scope of
upgrade command" threads).
Basically, the thread enforces the idea that setup.py, bin/, and
python_lib/ are quickly-owned files (well, the bottom part of setup.py
is user-owned).
That means that every time the user runs a new version of quickly, it
will automatically overwrite the parts that are quickly-owned with the
latest version.
This saves us bucket loads of effort trying to sed files every time we
come up with an incremental improvement. Being so cautious is also a
frequent difficulty in reviewing branches where a drive by contributor
doesn't realize the possible upgrade concerns (or even quickly
developers ourselves forget). Basically, it lets us make changes
quicker and with more confidence.
Tony was kind enough to review the merge a bit and suggested we talk
about this on the mailing list. I believe his big concerns were
around when users want to workaround quickly bugs or features they
don't like. They may patch quickly-owned files and lose the changes.
My answer is that after setup.py launches your module's python.main(),
you can do whatever you like in that function. So as long as we don't
crash in bin/python-name or setup.py, you can adjust behavior in your
own code. There shouldn't ever be a reason to touch quickly-owned code.
Alternatively, the user could bzr revert the changes manually.
[1] https://code.launchpad.net/~mterry/quickly/overwrite/+merge/111315
<https://code.launchpad.net/%7Emterry/quickly/overwrite/+merge/111315>
