Currently, running tests and installing the app requires the developer to install packages on the host directly, polluting the system with globally installed packages. This also implies that packages installed in the global scope could pollute the working environment. It would be neat if there was more isolation between twtxt and the machine used to run tests / develop on it.
Proposed solution
I would be tempted to add a bootstrapping script that would create a venv in which dev requirements and the app itself would be installed. This would ensure some isolation when iterating, as well as guarantee that we don't leak dependencies into the host system when someone sets everything up to run tests, lint or play around with the package.
Something following the general pattern of the Scripts to Rule Them All feels appealing and could feature a bootstrapping script that sets up a venv (if one doesn't already exists) and installs dependencies in it.
This would also make it easier to enforce something like a .python-versionfile to explicitly state what Python version development should happen in (i.e. anything >=3.7, based on the setup.py annotations).
As a side-benefit, it would also help standardize what is being installed in CI (since we could leverage it the frozen dev requirements instead of manually installing select packages and opening the door to human error / drift in requirements).
I'd be happy to put that together and push it up if there's interest!
Context
Currently, running tests and installing the app requires the developer to install packages on the host directly, polluting the system with globally installed packages. This also implies that packages installed in the global scope could pollute the working environment. It would be neat if there was more isolation between
twtxtand the machine used to run tests / develop on it.Proposed solution
I would be tempted to add a bootstrapping script that would create a venv in which dev requirements and the app itself would be installed. This would ensure some isolation when iterating, as well as guarantee that we don't leak dependencies into the host system when someone sets everything up to run tests, lint or play around with the package.
Something following the general pattern of the Scripts to Rule Them All feels appealing and could feature a bootstrapping script that sets up a venv (if one doesn't already exists) and installs dependencies in it.
This would also make it easier to enforce something like a
.python-versionfile to explicitly state what Python version development should happen in (i.e. anything >=3.7, based on thesetup.pyannotations).As a side-benefit, it would also help standardize what is being installed in CI (since we could leverage it the frozen dev requirements instead of manually installing select packages and opening the door to human error / drift in requirements).
I'd be happy to put that together and push it up if there's interest!