1 |
Am Mittwoch, 11. März 2020, 21:27:11 CET schrieb Grant Edwards: |
2 |
> On 2020-03-11, Marc Joliet <marcec@×××.de> wrote: |
3 |
> > Am Mittwoch, 11. März 2020, 18:54:43 CET schrieb Grant Edwards: |
4 |
> >> [...] |
5 |
> >> Q: Under what conditions will having a second installation of a Python |
6 |
> >> |
7 |
> >> library under .local cause problems? |
8 |
> > |
9 |
> > IIUC you shouldn't have any problems, simply because ~/.local/ is not part |
10 |
> > of the system python's module search path: |
11 |
> > |
12 |
> > % python3 |
13 |
> > Python 3.6.10 (default, Feb 26 2020, 01:09:02) |
14 |
> > [GCC 9.2.0] on linux |
15 |
> > Type "help", "copyright", "credits" or "license" for more information. |
16 |
> > |
17 |
> >>>> import sys |
18 |
> >>>> sys.path |
19 |
> > |
20 |
> > ['', '/usr/lib64/python36.zip', '/usr/lib64/python3.6', |
21 |
> > '/usr/lib64/python3.6/ lib-dynload', |
22 |
> > '/usr/lib64/python3.6/site-packages'] |
23 |
> |
24 |
> Except it is for me (and I don't know how it gets there): |
25 |
> |
26 |
> $ which python |
27 |
> /usr/bin/python |
28 |
> |
29 |
> $ file /usr/bin/python |
30 |
> /usr/bin/python: symbolic link to python-exec2c |
31 |
> |
32 |
> $ file /usr/bin/python-exec2c |
33 |
> /usr/bin/python-exec2c: ELF 64-bit LSB pie executable, x86-64, version 1 |
34 |
> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for |
35 |
> GNU/Linux 3.2.0, stripped |
36 |
> |
37 |
> $ set | grep -i py |
38 |
> |
39 |
> $ python |
40 |
> Python 3.6.10 (default, Feb 26 2020, 16:43:12) |
41 |
> [GCC 9.2.0] on linux |
42 |
> Type "help", "copyright", "credits" or "license" for more information. |
43 |
> |
44 |
> >>> import sys |
45 |
> >>> sys.path |
46 |
> |
47 |
> ['', '/usr/lib64/python36.zip', '/usr/lib64/python3.6', |
48 |
> '/usr/lib64/python3.6/lib-dynload', |
49 |
> '/home/grante/.local/lib64/python3.6/site-packages', |
50 |
> '/usr/lib64/python3.6/site-packages', |
51 |
> '/usr/lib64/python3.6/site-packages/pygdbmi-0.8.4.0-py3.6.egg', |
52 |
> '/usr/lib64/python3.6/site-packages/pcpp-1.1.1-py3.6.egg', |
53 |
> '/usr/lib64/python3.6/site-packages/pytz-2019.2-py3.6.egg', |
54 |
> '/usr/lib64/python3.6/site-packages/python_dateutil-2.8.0-py3.6.egg'] |
55 |
> |
56 |
> |
57 |
> The entry for /home/grante/.local/lib64/python3.6/site-packages (where |
58 |
> pip --user installs things) is in my path. |
59 |
|
60 |
You're right, I forgot that you would have used the system-wide pip and that |
61 |
it probably manipulates your sys.path appropriately (I don't know exactly how, |
62 |
though). What I wrote only holds if you use virtualenvs (and for system |
63 |
packages that don't run as your user). I suppose those are the most |
64 |
straightforward way to achieve what you want. To that end you could check |
65 |
"python -m venv -h" in a terminal to get started, IIRC venv is the modern |
66 |
standard way of creating virtualenvs (I don't use it myself, as I require |
67 |
other binary packages that only conda provides). You would then use the |
68 |
virtualenv's pip to install your software. |
69 |
|
70 |
-- |
71 |
Marc Joliet |
72 |
-- |
73 |
"People who think they know everything really annoy those of us who know we |
74 |
don't" - Bjarne Stroustrup |