On 07Jan2017 12:22, jim <jf_byr...@comcast.net> wrote:
On 01/06/2017 08:24 PM, Cameron Simpson wrote:
On 06Jan2017 23:03, Clint Moyer <cont...@clintmoyer.com> wrote:
Packages supplied by your distribution can be trusted more than packages
from PyPi. Just my two cents.
Most distros offer nearly all the useful Python modules directly from the
repo.
I would agree with this on the whole. And also that it is generally
better to add modules to your system python via the distro's repo
because that bring benefit to every user on the system, not just yourself.
What is "system python"? If I do $ which python I get /usr/bin/python
which points to python 2.7xx. So if everything I added was for python
3 either using pip3 or apt-get would I be adding to "system python"?
Whatever python(s) came from the vendor. If they're in /bin or /usr/bin, then
they will almost certainly be the vendor python.
The thing is, many distros will have an aim to move to python 3 as their python
for tooling (python 2 is essentially maintenance only - see PEP 404), and there
will be a mix of python 2 and python 3 programs on your system, both core
vendor-made tools (eg yum on redhat/centos) or third party but vendor supplied
stuff (== anything else that apt-get will give you).
Basicly, for Ubuntu the "system" python is anything supplied by apt-get and
therefore _managed_ by apt. This is why you should avoid "become root and run
pip3 install" on the whole - you may well tread in the space owned by the
vendor because Ubuntu supply many python packages.
Normally a vendor will not install its packages in /opt or /usr/local or in
/home/wherever; that leaves such spaces as safe for third party stuff installs.
So, instead, make a python3 virtualenv as yourself and use _its_ pip3 for
installs; they will land in the virtualenv, away from the vendor files.
When you make a virtualenv you base it on an existing python; if you tell it to
use /usr/bin/python3 that will be the underlying python executable, but the
"python3" from inside the virutalenv will be configured to use the virtualenv's
packages.
I generally configure my virtualenvs to leverag the system's packages, as this
lets me benefit if more vendor supplied packages are added. (Some virtualenvs
are not, in order to isolate them from changes.)
Here's an example:
$ mkdir ~/var ~/var/venv # where I keep my virtualenvs
$ virtualenv -p /usr/bin/python3 --system-site-packages ~/var/venv/3
$ ~/var/venv/3/bin/python3 # invokes the virtualenv python3
$ ~/var/venv/3/bin/pip3 # invokes the virtualenv pip3
$ ln -s ~/var/venv/3/bin/python3 ~/bin/. # make these my default
$ ln -s ~/var/venv/3/bin/pip3 ~/bin/.
From this point on "pip3" should execute your own $HOME/bin/pip3, which comes
from the virtualenv and installs in ~/var/venv/3/lib/...
In this way:
- you get whatever vendor supplied packages there are, including any updates
- you can install freely with pip3 safe in the knowledge that it will be in
~/var/venv/3, away from the system packages; pip3 install packages will
override any vendor supplied one for the venv python3
A number of years ago I had virtualenv installed. At the time I remember it
took me a while to get it installed and working.
It is almost a one liner these days, see example above.
Right now I am working on some scripts to download some financial date using
Selenium and paste it into Libreoffice Calc spreadsheets. Will using
virtualenv have any effect on me running those scripts?
I wouldn't think so. Especially if they already work.
Cheers,
Cameron Simpson <c...@zip.com.au>
--
https://mail.python.org/mailman/listinfo/python-list
