- Clone the repository
- Change to the root directory
pip install -r requirements.txt
vit/command_line.py
is the entry point for the application. To run it without a full installation:- Set the
PYTHONPATH
environment variable to the root directory of the repository - Run it with
python vit/command_line.py
- A snazzier option is to create a command line alias. For Bash:
alias vit='PYTHONPATH=[path_to_root_dir] python vit/command_line.py'
- ...or a shell function. For Bash:
vit() { cd ~/git/vit && PYTHONPATH=${HOME}/git/vit python vit/command_line.py "$@" } export -f vit
- Set the
- Located in the
tests
directory - Run with
./run-tests.sh
VIT comes with a simple debug
class for pretty-printing variables to
console or file. The file's default location is vit-debug.log
in the
system's temp directory.
Usage in any of the code is straighforward:
import debug
debug.console(variable_name)
debug.file(variable_name)
Whereas VIT 1.x simply layered an
ncurses
interface over CLI calls to the task
binary, VIT 2.x handles
data/reporting differently:
- Data is read from Taskwarrior via the export functionality using tasklib
- Reports are generated via custom code in VIT, which allows extra features not found in Taskwarrior. Most report-related settings are read directly from the Taskwarrior configuration, which mostly allows a single point of configuration
- Data is written to Taskwarrior using a combination of
import
commands driven by tasklib, and CLI calls for more complex scenarios
For any developer managing VIT releases, here's a simple checklist:
- Check
requirements.txt
, and bump any dependencies if necessary - Check
setup.py
, and bump the minimum Python version if the current version is no longer supported
- Bump the release number in
vit/version.py
- Generate changelog entries using
scripts/generate-changelog-entries.sh
- Add changelog entries to
CHANGES.md
- Commit
- Add the proper git tag and push it
- Create a Github release for the tag, use the generated changelog entries in the description
- Build and publish PyPi releases using
scripts/release-pypi.sh
- Announce on all relevant channels
The long-term vision is:
- Solid test coverage
- Plenty of inline documentation
- An interface-driven, modular design that allows most components to be overridden/customized
- A plugin architecture where appropriate (a good example would be the elements of the top status bar -- each element could be a plugin, allowing third-party plugins to be written and used in that portion of the app)