Code review comment for ~mpontillo/uvtool:dev-env-setup-and-hacking-instructions

I think we agree on most of these items, so let me just address where we
may disagree.

> Asking contributors to run the single line "PYTHONPATH=. bin/..." or
> "setup.py test" or whatever is however immediately transparent. The
> former because it's a one-liner that does nothing special and should be
> immediately understandable to a Python developer, and the latter because
> it uses setuptools, which should also be immediately understandable to a
> Python developer.

What I don't like about "PYTHONPATH=. bin/..." is that it considerably
slows development. Maybe it's just me, but I was doing just that when
poking around with `uvtool` for quite some time. (Until I decided to
scratch this itch.) If I'm in a shell and I'm looking at code, testing
things out, moving around to other directories outside my sandbox, etc,
it's really annoying to have to switch back to the sandbox root to test
things again, and slows me down considerably. And it's equally annoying if
I have to manually export environment variables each time. And if I forget
something or make a typo, guess what: I'm testing the global `uvtool`, and
I get frustrated when I realize I'm testing the wrong code. When I find
myself doing something manual like that over and over again, it either
drives me insane, or I want to automate it. ;-)

> As it isn't uvtool-specific, it does not belong in uvtool. As it's a
> general problem, it should be solved in a general way with generic
> tooling that the whole community can use. This may be setuptools or
> virtualenv or something else. If a Python community member's
> expectations are broken because uvtool's tree detracts from convention,
> then we should fix that. And I'll accept patches and encourage that side
> of things being fixed.

I see your point here and mostly agree. If you're against the addition of a
contrib/ script for this, I can keep it as a local helper script for
myself. But I think it's a bit of a shame that others can't take advantage
of it.

Moving to a pure virtualenv model (or whatever Pythonic tool is chosen)
would be great, and I support that. (But I would still want something to
automate the creation of a dev env. It takes too much mental energy for me
to manage venvs manually, when I would rather be working on the code.)

The fact is, right now `uvtool` is *very* Ubuntu specific. Getting a
development environment up and running, correspondingly so. I think you
don't like that I have codified that. ;-) If all the dependencies are
available in pypi and `setup.py` works as a typical Python developer
expects, I think that would also solve the issue. But that is a patch that
reaches into simplestreams and other projects, and I don't have time to
work on that.