417
edits
FFGo: Difference between revisions
Jump to navigation
Jump to search
→Using pip (generic method): Add section “When the base Python installation is updated or removed”
m (→Using pip (generic method): Section renaming) |
(→Using pip (generic method): Add section “When the base Python installation is updated or removed”) |
||
| Line 703: | Line 703: | ||
If you'd rather get rid of the whole virtual environment, just delete its base | If you'd rather get rid of the whole virtual environment, just delete its base | ||
directory <venv-dir>. That is all there is to it! | directory <venv-dir>. That is all there is to it! | ||
====== When the base Python installation is updated or removed ====== | |||
Let's say you built a virtual environment using a command such as: | |||
<syntaxhighlight lang="shell" enclose="div"> | |||
/usr/bin/python3.4 -m venv <venv-dir> | |||
</syntaxhighlight> | |||
In such a case, your virtual environment located in <venv-dir> is somehow | |||
linked to its <i>base Python installation</i>, the one providing | |||
<tt>/usr/bin/python3.4</tt>. If you are on Debian for instance, this base | |||
Python installation comes from the <tt>python3.4</tt> package. So, what happens | |||
when this package is updated or removed? | |||
<ul><li> | |||
<p>My experience didn't show any particular problem so far when the package | |||
for the venv's underlying base installation is updated. I suppose this will be | |||
more or less always like that as long as updates are reasonable in terms of | |||
backward-compatibility—which is normally the case when the Python major | |||
version isn't changed (here: 3.4).</p> | |||
<p>Note:</p> | |||
<blockquote> | |||
It is possible to pass the following option upon venv creation (i.e., after | |||
something like <code>/usr/bin/python3.4 -m venv</code>): | |||
<pre>--upgrade Upgrade the environment directory to use this version | |||
of Python, assuming Python has been upgraded in-place.</pre> | |||
(this can be found by running, e.g., <code>/usr/bin/python3.4 -m venv --help</code>) | |||
Since venv creation using a script is extremely fast, I haven't felt any need | |||
for this option so far, and thus have no experience to share regarding it. | |||
</blockquote> | |||
</li> | |||
<li> | |||
<p>However, when you upgrade your Linux/BSD/etc. distribution, it may happen | |||
that for instance Python 3.4 is removed and replaced with Python 3.5. This is | |||
not very frequent, but it does happen. In such a case, your virtual | |||
environments built from <tt>/usr/bin/python3.4</tt> are quite likely not to | |||
work anymore.</p> | |||
<p>The cure for this kind of problem is not very difficult: just delete the | |||
concerned virtual environments and recreate them using the new Python | |||
interpreter of your choice (e.g., <tt>/usr/bin/python3.5</tt>). To facilitate | |||
this, and also as a convenient means of remembering exactly which commands you | |||
ran to create your virtual environment, I suggest to keep a short script | |||
containing exactly the commands you used to create the venv. For instance:</p> | |||
<syntaxhighlight lang="shell" enclose="div"> | |||
#! /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 Pillow geographiclib FFGo | |||
</syntaxhighlight> | |||
<p>This script takes one optional argument: the base path where you want the | |||
virtual environment to be created (represented by <venv-dir> above). As the | |||
script is written, this argument defaults to <i>default-venv-dir</i> in the | |||
current directory, but you can of course replace this with any path of your | |||
choice.</p> | |||
<p>Note:</p> | |||
<blockquote> | |||
This script installs FFGo inside the virtual environment. If you want to use | |||
FFGo from its Git repository instead, just replace <tt>FFGo</tt> with | |||
<tt>CondConfigParser</tt> in the last line of the script (since CondConfigParser is a mandatory dependency of FFGo). | |||
</blockquote> | |||
</li> | |||
</ul> | |||
==== MacOS X ==== | ==== MacOS X ==== | ||