Manage your workspaces and increase your productivity.
Worky is a tool that helps to define and load project workspaces. It can be used to load a project workspace with a single command and quickly start your work. Worky saves you from wasting time doing repetitive tasks before actually starting to work. This project can be used for every type of project or workspace, the only limitation is due to the functionality of the programs that you can run from CLI.
Please note that this is a work-in-progress tool. If you have any ideas or suggestions, please open an issue or a pull request. Any helps is appreciated. Here is a list of future improvements:
- Add the window manager support to open programs in a specific workspace/monitor.
This project uses Poetry to manage dependencies and packaging and it is available on PyPI. To install it, simply run:
pip install worky
If you are on an arch-based distro and can access to the Arch Linux Repository (AUR) you can install worky using an AUR helper like yay:
yay -S worky
If you prefer a practical way to understand how to worky configuration works, you can take a look at the examples directory.
There are multiple ways to configure worky:
- Worky automatically looks for a
.worky.toml
file in the current directory where is called. - You can create a
~/.config/worky/{{project_name}}.toml
file and worky will automatically look for it when you runworky project_name
. For example, if you have a project namedmy_project
you can create a~/.config/worky/my_project/config.toml
file and useworky my_project
to load the project workspace. - You can create a subdirectory named as your project (
project_name
) under the~/.config/worky/
. Here you can put yourconfig.toml
file and worky will look for it when you runworky project_name
. For example, if you have a project namedmy_project
you can create a~/.config/worky/my_project/config.toml
file and useworky my_project
to load the project workspace. - You can specify a configuration file using the
-c
flag followed by the path of the config file (seeworky --help
for more details).
Variables can be defined in the [variables]
section of the configuration file. The variable's value is the command to be executed.
The variables can be used in all the config file except for the steps name.
The value of the variables used in the step name defines the command that will be executed. See the steps section for more details.
The steps are the commands that will be executed when you load the workspace. The command is defined by the step name using a variable.
For example, if you have a variable named backend
with the value idea
you can define a step named backend
and worky will run the idea IDE.
Steps can have an args
property that is a list of arguments to be passed to the command when it is executed.
An example of an argument can be the path of the project to open but this strictly depends on the program that you want to load.
Steps can have a condition
property that is the name of a flag that you can pass when you run worky that defines if the step should be executed or not.
For example, if you want to run a docker-compose
command only if you pass the -f docker
flag you can define a step like this:
[variables]
compose = "docker-compose"
[compose]
condition = "docker"
args = [
"-f",
"/path/to/docker-compose.yaml",
"up"
]
Then you can run worky -f docker
to load the workspace and run the compose
step.
You can create an alias by simply create a symbolic link to your config file in the ~/.config/worky/
directory.
ln -s ~/.config/worky/very_long_project_name.toml ~/.config/worky/aliased_name.toml
Then you can use both worky very_long_project_name
and worky aliased_name
to load the workspace.
Worky configuration depends on the TOML syntax. This means that you can't create two steps with the same name. You can crate two different steps using variables with the same value. Moreover, this helps to keep the configuration file clean and readable.
After installing and configured worky, you can use it to load your project workspace simply by running:
worky # If you have a .worky.toml file in the current directory
# or
worky {{project_name}} # If you have a config file in ~/.config/worky/{{project_name}}/config.toml or ~/.config/worky/{{project_name}}.toml
# or
worky -c {{path_to_config_file}} # Defining a custom config file
Install dependencies:
pyenv local 3.10 # Or higher like 3.11.1
poetry use env 3.10
poetry install
poetry run worky {{your_command_args}}
After you have made your changes, if you have changed something in the pyproject.toml
use poetry2setup
dev dependency to update setup.py
:
poetry2setup > setup.py
Then build the package with poetry build
and create a PR with your changes if there are no issues.
If you appreciate my work I will appreciate if you buy me a coffee.