You can manage virtualenv based utilities with this utility. Its primary use in addition to installing and updating is creating links (in /usr/local/bin) for utilities that are installed in separate virtualenvs.
Originally it only created alias definitions that could be 'sourced' into bash. But those aliases were difficult to use from non-login shells (and crontab etc). It still can generate those aliases, but only does so for those commands for which it cannot find a link in /usr/local/bin/
In such a setup, where you have a separate virtualenv for each utility, you don't want to extend your path with the bin directory of each of the virtualenvs, as that gives you:
If during install / update /usr/local/bin cannot be written to, the program will call sudo ln -s /usr/local/bin/yourutil /opt/util/yourutil/bin/yourutil (or similar) that will prompt you for the root privilages password.
Of course directly specifying the full path to your virtualenv based utility works as well.
This is no longer needed.
virtualenvutils alias dir1 dir2 scans directories, non-recursive, under dir1`, ``dir2 for virtualenvs. Any directory containing bin, lib, include subdirectories as well as a file bin/activate is considered a virtualenv.
For any of those virtualenvs it does one of following (checked in this order):
the utility then generates aliases for all utilities found this way, making sure they are unique if added by the last method, and writes those alias definitions to stdout. Any error go to stderr.
Other functionalities include:
see virtualenvutils --help for the full list of subcommands
The virtualenvutils.conf file, if provided, has to be in the toplevel directory of the virtualenv (i.e. next to bin, include and lib and consist of single line with or without a colon (:).
If there is no colon, then the line is considered to be the name of an executable file under that virtualenvs bin.
If there is a colon, the part before the colon is considered the name for executable under bin, for which the executable name is the part behind the colon.
You want to install docker-compose in a virtualenv. If you do:
mkvirtualenv -p /opt/python3/bin/python /opt/util/docker-compose source !$/bin/activate pip install docker-compose deactivate
you will need to call it with:
/opt/util/docker-compose/bin/docker-compose
If you would have specified a different final directory:
mkvirtualenv -p /opt/python3/bin/python /opt/util/compose source !$/bin/activate pip install docker-compose deactivate
you will need to use:
/opt/util/compose/bin/docker-compose
The above can resp. be done using virtualenvutils by using:
virtualenvutils install /opt/util/docker-compose
and:
virtualenvutils install /opt/util/compose --pkg docker-compose
respectively. In both instances a link /usr/local/bin/docker-compose will be created that will be able to start your utility.
To bootstrap virtualenvutils:
mkvirtualenv -p /opt/python3/bin/python /opt/util/virtualenvutils source !$/bin/activate pip install virtualenvutils virtualenvutils update virtualenvutils # this will create the link deactivate
after which you can use plain virtualenvutils as long as /usr/local/bin is in your PATH.
You can update all packages for all virtualenv utilities (under /opt/util) by using:
virtualenvutils update /opt/util
The arguments to update are checked to see if they are virtualenvs. If they are they get update on an individual basis. If they are not (as in the above example) each of their subdirs are checked to be virtualenvs (non-recursive).
You can install one or more new virtualenv based utilities using something like:
virtualenvutils install /opt/util/{docker-compose,ruamel.yaml.cmd}
You can use --pkg to give a package name that differs from the final part of the path (in which case you can of course only specify one path), and with --python /opt/python/3/bin/python you can explicitly specify the python version to use.
Don't forget that you probably have to logout and login for if you set your aliases through as scan initiated in .bashrc, before you can use the commands.