Running
Drop’s workflow is inspired by Python’s virtualenv: create an easily disposable environment, enter it, work normally - but with enforced sandboxing.
Create a new Drop environment
drop init [ENV_ID] creates a new Drop environment. If ENV_ID is
missing, Drop derives the id from your current working
directory path. For example:
alice@zax:~/project$ drop init
Drop environment created with config at /home/alice/.config/drop/home-alice-project.tomlThe environment gets read-write access to the directory in which drop init was run; see Sharing the project
directory.
Run a sandboxed program
drop run [-e ENV_ID] [command] runs the command within the sandbox.
If [-e ENV_ID] is not passed, Drop derives the id from your current
working directory path.
If [command] is not passed, it defaults to $SHELL, so to start a
sandboxed shell you can simply use:
alice@zax:~/project$ drop runWithin the environment the sandbox restrictions are applied:
(drop)alice@zax:~/project$ file ~/.ssh
/home/alice/.ssh: cannot open `/home/alice/.ssh' (No such file or directory)
(drop)alice@zax:~/project$ echo "evil command" >> ~/.bashrc
bash: /home/alice/.bashrc: Read-only file systemManaging Drop environments
Drop environments are persistent. If a process started by drop run
terminates, the environment is still there and the files created by
the process are kept.
For example, create a new_file within an environment webapp:
$ drop run -e webapp bash -c 'echo hello > ~/new_file'A subsequent drop run within the same environment still sees the
created file:
$ drop run -e webapp cat ~/new_file
hellodrop ls lists all the created environments; drop rm removes an
environment and all its files.
With Drop environments you don’t need to track what files and dirs programs create in your home dir. Each environment has its own home dir, which is removed together with the environment.
Other commands
drop help- prints usage and available commandsdrop COMMAND help- prints command-specific help, lists options supported by the commanddrop update --check- checks if a new version of Drop is available
Sharing the project directory
When you work on a project, you usually want convenient access to the project files to edit them, review changes, commit and push. You may also prefer for the project files to be stored within your normal home directory tree, not in the Drop environment dirs.
To help with this, drop init configures the created environment to
have read-write access to the directory in which drop init was run,
except for its .git subdirectory, which is read-only. This is done
only if the current working directory is not your home dir or a parent
of it, to avoid exposing the whole home dir to the sandbox.
If you don’t want to expose the current directory to the created
environment, pass the --no-cwd flag:
drop init --no-cwdAt any time you can also edit the TOML config generated by drop init to add or remove exposed directories.