Merge ~mpontillo/uvtool:dev-env-setup-and-hacking-instructions into uvtool:master
Status: | Needs review |
---|---|
Proposed branch: | ~mpontillo/uvtool:dev-env-setup-and-hacking-instructions |
Merge into: | uvtool:master |
Diff against target: |
140 lines (+110/-0) 5 files modified
.gitignore (+1/-0) HACKING.md (+31/-0) Makefile (+15/-0) contrib/develop (+59/-0) contrib/get-sandbox-path (+4/-0) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
uvtool development | Pending | ||
Review via email: mp+314118@code.launchpad.net |
Commit message
Add contrib/
* This script is intended to keep up with packaging so that new developers
can easily install the depenencies and begin work.
* Touches a '.installed' file in the sandbox to prevent doing more work
than necessary.
Add utility scripts to make development easier.
* New script: contrib/develop - when sourced, sets up $PATH and
$PYHONPATH for development with the current sandbox.
* New script: contrib/
the full path to the current sandbox. (Useful for setting up
the $PATH and $PYTHONPATH automatically.)
* Added Makefile whose default target ensures that development
dependencies are installed, and then prompts the user to set up
their environment correctly (by sourcing contrib/develop).
Add HACKING.md file.
* Contains a short introduction regarding how to start development.
I appreciate and agree with having a HACKING.md. But rather than having a bunch of extra infrastructure, can we not just say, in HACKING.md:
Debian/Ubuntu build/runtime dependencies: <package1> <package2> ...
To run from the working tree, from the top level use: PYTHONPATH=. bin/uvt-kvm ...
Is there anything else required? By the time a new contributor has read HACKING.md and learned to run the "make install- dependencies" command, he/she might as well have learnt to just run "apt install ..." directly and be ready. The same goes for learning about the contrib/develop script.
I'm skeptical about a bunch of infrastructure that I feel is unnecessary. Contributors would end up having to learn what we have set up, and we would have to maintain it. Further, I expect there to be convention on this sort of thing and for us to follow it.
I think less is more here. I certainly get put off when arriving at a new project and finding a non-trivial development setup, such as custom non-standard code to run just to get things going.