Using sudo with pip3?

[Cameron Simpson]

On 07Jan2017 12:22, jim <jf_byrnes at comcast.net> wrote:
>On 01/06/2017 08:24 PM, Cameron Simpson wrote:
>>On 06Jan2017 23:03, Clint Moyer <contact at 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 <cs at zip.com.au>