workenv
A shortcut for jumping between local work environments in bash, and carrying out tasks within them.
Requires Python 3.7+ and bash.
Quick example
Example ~/.workenv_config.yml:
myproject:
path: /path/to/myproject
source: venv/bin/activate
run:
- nvm use
commands:
database:
run: docker-compose up database
otherproject:
file: /path/to/otherproject
Example usage:
# Jump to /path/to/myproject with the local python virtual environment and nvm
we myproject
# Jump to /path/to/myproject and run the database container
we myproject database
# Bash completion support
we m<tab> d<tab>
There is also support for a _common project with values applied to all projects, and
for projects which define their own settings locally in ,workenv.yml files - see docs
below.
Installation
Recommended: Install using pipx:
pipx install workenv
workenv --install
Alternative: Install to a virtual environment with::
cd path/to/installation
python -m venv venv
source venv/bin/activate
pip install workenv
workenv --install
Both of these options will add the command as we by adding a line to your .bashrc.
If you would prefer a different command name, you can specify it when installing:
workenv --install workon
Restart your shell session for your change to take effect.
To uninstall, remove the line from .bashrc, and either uninstall with pipx or delete
your virtual environment.
Configuration
Add the current path as a new project:
we --add projectname
Add the current path as a new command::
we --add projectname command
Open your .workenv_config.yml for customisation::
we --edit
The top level of the YAML file are the names of the projects.
Values can substitute the project name with {{project.name}} or {{project.slug}}.
Special rules
There are two special top-level YAML objects:
_config
Controls settings:
verbose- iftrue, show bash commands when running themhistory- iftrue, add the commands to history
_common
Common project which can define a common source, env, run and commands
which will be added to all other projects, regardless of whether they define their
own.
The common project cannot specify a path.
Project rules
A project can have the following attributes:
path
The path to set as the current working directory. This will be the first command run.
Example:
myproject:
path: /path/to/foo
Bash equivalent:
cd /path/to/foo
source
Path or paths to call using source
Example:
myproject:
source:
- venv/bin/activate
- .env
Bash equivalent:
source venv/bin/activate
source .env
env
Dict of environment variables to set
Example:
myproject:
env:
COMPOSE_PROJECT_NAME: my_project
Bash equivalent:
export COMPOSE_PROJECT_NAME=my_project
run
Command or list of commands to run
Example:
myproject:
run:
- nvm use
- yvm use
Bash equivalent::
nvm use
yvm use
commands
Dict of Command objects
Example:
myproject:
commands:
database:
run: docker-compose up database
Usage:
we myproject database
Bash equivalent:
docker-compose up database
A command will inherit the path and env of its parent project, unless it defines its
own.
It will inherit the source of its parent project only if it does not specify its own
path or source.
A command can have the same attributes as a project, except it cannot define its own
commands.
Full example
Putting together all the options above into a sample .workenv_config.yml:
_config:
verbose: true
history: false
_common:
env:
COMPOSE_PROJECT_NAME: '{{project.slug}}'
PS1: '"\[\e[01;35m\]{{project.slug}}>\[\e[00m\]$PS1"'
commands:
open:
run: xdg-open .
myproject:
path: /path/to/myproject
source:
- venv/bin/activate
- .env
run:
- ./manage.py migrate
- ./manage.py runserver 0:8000
commands:
database:
run: docker compose up database
other:
path: /path/to/other
something-else:
config: /path/to/somethingelse
we myproject is equivalent to typing:
cd /path/to/myproject
source venv/bin/activate
source .env
export COMPOSE_PROJECT_NAME=myproject
./manage.py migrate
./manage.py runserver 0:8000
we myproject database is equivalent to typing:
cd /path/to/myproject
source venv/bin/activate
source .env
export COMPOSE_PROJECT_NAME=myproject
docker compose up database
we other is equivalent to typing:
cd /path/to/other
export COMPOSE_PROJECT_NAME=other
we other open is equivalent to:
cd /path/to/myproject
export COMPOSE_PROJECT_NAME=other
xdg-open .
and something-else will be configured in /path/to/somethingelse/.workenv.yml; path
will be automatically set to that dir:
source:
- venv/bin/activate
- .env
run:
- ./manage.py migrate
- ./manage.py runserver 0:8000
commands:
database:
run: docker compose up database
Metadata
Release files for workenv 2.1.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| workenv-2.1.3.tar.gz | 14.5 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| workenv-2.1.3-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 26.8 kB
Release files / workenv-2.1.3.tar.gz
| Download URL | workenv-2.1.3.tar.gz |
|---|---|
| Size | 14.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
fbd3b8133862588fee6eba2e6ff338b478ce4de05fad4dca586a291cf99d0501
|
|
BLAKE2b-256 checksum How to use checksums |
628ea4fc952a280814966a2044fa0d283dc3cb775199704e1172914c9b7f9d74
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Feb 24, 2026.
Transparency logRelease files / workenv-2.1.3-py3-none-any.whl
| Download URL | workenv-2.1.3-py3-none-any.whl |
|---|---|
| Size | 12.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
a0f88544ccc3ffa29ef7907645c0911d3f1b1a803173bec412fccf5b783092ec
|
|
BLAKE2b-256 checksum How to use checksums |
88cd6b21753893afbdd33c707c8076206f0f761418155e0a2862844a4af16352
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Feb 24, 2026.
Transparency log