Hi,
chris_blues wrote in Tue Jan 26, 2016 12:06 am:That's it. This certain command installs the software into the created environment, as a "make install" would install some software into my OS.
Right. And the particular environment where it is installed is the one living in <venv-dir> when you run the command:
- Code: Select all
<venv-dir>/bin/pip install package_1 ... package_n
which is why, until you are comfortable with pip, I suggest to use such a command rather than resorting to one of the shortcuts that allow writing the shorter:
- Code: Select all
pip install package_1 ... package_n
When you use a syntax such as '<venv-dir>/bin/pip ...', you know that it is going to operate on, or report from the venv living under <venv-dir>. It may seem a bit long to type, but with shell completion and command history (Up arrow...), the advantage in clarity outweighs this little inconvenience IMHO (it's only bothersome for me when writing instructions, as I would like them to be as short as possible to avoid scaring potential users...).
chris_blues wrote in Mon Jan 25, 2016 2:56 pm:Ah ok, it doesn't exactly install into the venv, but instead use the code "out-of-venv" from my git-clone. That piece was missing!
After I set up my venv with pillow & Co, without FFGo, I do call FFGo from that environment.
Right, using <venv-dir>/bin/python to start the ffgo-launcher.py script located inside your Git clone of the repo (which itself is going to import many Python modules located in the Git clone).
Concerning Pillow, note that installing or upgrading it with pip will automatically compile it (it contains a lot of C code), which can only succeed if you have the appropriate C compiler (gcc works) and headers. On Debian, installing 'gcc libpython3-dev tcl-dev tk-dev' with apt-get or aptitude should be enough (at least, it was for me). On Windows, this is most of the times not necessary, because the PyPI site from which pip downloads packages by default contains binary distributions of Pillow for many Python and Windows versions.
Yes, but I would probably chain the commands like this:
- Code: Select all
cd "$ffgo_git_dir" && git pull && make
or add 'set -e' at the top to make sure the script stops at the first error.
Additionally, such a script only updates FFGo. As for security updates on any OS, you should update your venvs from time to time IMHO. This can be done manually with:
- Code: Select all
<venv-dir>/bin/pip list --outdated
followed by:
- Code: Select all
<venv-dir>/bin/pip install --upgrade <pkg_1> ... <pkg_n>
for the packages you want to upgrade. There is unfortunately no pip command to upgrade all packages contained in a venv at once, because apparently the pip developers and users are still hesitating about the syntax to adopt concerning shallow vs. recursive upgrades, and whether to break compatibility in order to introduce the “optimal” behavior... (cf.
pip issue 59). If you really want to automate this step, a script such as:
- Code: Select all
#! /bin/sh
#
# Work around the absence of an 'upgrade-all' command in pip (2016-01-26)
#
# cf. <https://github.com/pypa/pip/issues/59>
set -e
progname=$(basename "$0")
venv_path="$1"
if [ -z "$venv_path" ]; then
echo "$progname: empty venv path, aborting." >&2
exit 1
fi
# awk '!/Could not|ignored/ ...
# ignore warnings that may reported by 'pip list --outdated'
# xargs -n1
# upgrade one package at a time: avoid that a failed upgrade blocks
# all others
"$venv_path/bin/pip" list --outdated | \
awk '!/Could not|ignored/ { print $1 }' | \
xargs -n1 "$venv_path/bin/pip" install --upgrade
should do the trick. It takes one argument: a path to the venv in which you want to upgrade all packages (<venv-dir> in what I wrote above).
Edit: fix a bug in the above venv-updating script, replacing “pip” in the last line with “"$venv_path/bin/pip"” (I had tested the script on my main venv only, where it doesn't make any difference...).
There is one last thing to consider regarding upgrades. If your venv was built from /usr/bin/python3.4 for instance (with a command such as '/usr/bin/python3.4 -m venv <venv-dir>'), then it is somehow linked to its base installation: the one containing /usr/bin/python3.4. Thus, when your Linux distro removes /usr/bin/python3.4, of course you should expect the venv not to work anymore. Granted, it is a rare event in general, but I think it is a good idea to have a very simple venv-creation script that acts both as a reminder (which commands did I do to prepare this *@#]$ venv?..) and as a quick way to recreate it when needed, or to create another one for experimenting (venv creation is very, very fast). I sent you the script for my “main venv” by mail, but a simplified script creating a venv just containing FFGo's dependencies (suitable for using FFGo form Git) could look like:
- Code: Select all
#! /bin/sh
set -e
target_dir="${1:-default-venv-dir}"
base_python="/usr/bin/python3.4"
if [ -e "$target_dir" ]; then
echo "!!Warning!! '$target_dir' already exists. If you continue, its"
echo " contents will be deleted. Press Enter to continue,"
echo " otherwise interrupt the script with Ctrl-C."
read dummy
fi
"$base_python" -m venv --clear "$target_dir"
"$target_dir"/bin/pip install --upgrade \
pip setuptools CondConfigParser Pillow geographiclib
It takes one optional argument: the base path where you want the venv to be created (i.e., <venv-dir> in what I wrote above). This argument defaults to 'default-venv-dir' in the current directory, but you may provide an absolute path if you wish. Those who want to use pip-installed releases of FFGo instead of using it from the Git repo can just add 'ffgo' to the list of packages to install in the last line of the script.
Wow.