I appreciate your concerns. I probably went a little crazy on this. Let me provide some context for this proposal...

As a new contributor to a project, the first thing you have to do is figure out how to work on the thing. So if you want to jump in and change the code, you might ask yourself a few questions:

(1) How do I do manual testing?
(2) How do I do automated testing?
      a. How do I run the unit tests?
      b. Is there a larger integration test or CI system I should be mindful of?
(3) How do I create a package to test with?

So I agree that a HACKING guide addresses (1) in a simple enough way. I could have started simple and did just that. But as I said, I went a little crazy and kept going. ;-)

If you want to address (2) you really want to have an automated way to get everything going, so that on a fresh image you can easily test all the things you need to test. I think it's good to have dev-env-setup activities written in code, so that they can later be automated.

This change doesn't address (3). Beyond running 'apt-get source', I don't have a clue where the debian/ directory is for uvtool, etc.

That aside, let me break down the changes so you understand the purpose for each one before you make a decision.

 * As a new contributor to a Python project, my first instinct was to look around in the setup.py and requirements.txt for what I would need to install from pypi to get going. I soon realized all that was missing
   - Solution: create a Makefile, to pique the interest of curious developers. This came somewhat from my experience working on MAAS, where there are some similarities to uvtool: it is a Python project, but it isn't based on dependencies from pypi; rather, it is based on dependencies from the Ubuntu archive. (In MAAS it is quite difficult to get going, and having the `make` targets really helps new developers. If something is going wrong, we can just say "did you run `make install-dependencies`?)
   - Suggestion: lose the script and just put the `sudo apt-get install -yu ...` in the Makefile. That way the list of dependencies for development and testing can be maintained in one place (as opposed to having to document it in the HACKING guide, and then repeating the same steps when writing automation scripts).
   - Side benefit: by automating this piece, we make it really easy to address (2) and run automated tests on a fresh Ubuntu image.

 * As a new contributor to uvtool, I might ask myself: given the lack of a `virtualenv` requirement and the need to test in the context of the actual Ubuntu system, how do I actually run this thing without creating a package and installing it? (Now, you and I have some experience with this, and could figure out quickly that we just need to set up the PATH and PYTHONPATH appropriately. But we have a lot of experience with this sort of thing. $RANDOM_NEW_CONTRIBUTOR might appreciate a little more help.)
   - Solution: Create a script (similar to how `virtualenv` works) to automatically set up the development sandbox.
   - Side benefit: there is no additional thinking required when you go to automate tests. Just ". contrib/develop" and you're done.

The other thing I would point out is, there is nothing about the `develop` script that is really specific to uvtool in particular. As long as it works, there is no code to maintain in there, and it can only lower the barrier to entry for new contributors.

I do think I'll replace the install-dependencies script with something simpler though.