From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Florents Tselai <florents(dot)tselai(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: doc: virtual envs with Pl/Python |
Date: | 2024-10-17 21:03:51 |
Message-ID: | 715682.1729199031@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:
> On Thu, Oct 17, 2024 at 1:10 PM Florents Tselai
> <florents(dot)tselai(at)gmail(dot)com> wrote:
>> Which means that if you want non-standard packages in your Pl/Python code,
>> you’ll have to `sudo python3 -m pip install` things
> Or `sudo apt install python3-<package>`, or `pip install --user
> <package>` as the database user, or...
> Virtualenvs are great -- I use them daily -- but there are plenty of
> different ways to use the standard interpreter, with other pros and
> cons.
What I'm still confused about is whether this is anything that
a typical user of Python shouldn't be expected to know already.
I understand the idea of setting up a virtualenv that is decoupled
from the system-supplied package set, but if the user has done
that, wouldn't they already know about setting PYTHONPATH?
I can believe that they might not be totally clear on how to
set it in a way that will affect the Postgres server --- but
the proposed patch provides no details about that, and hardly
could since it'd vary so much from one server packaging to
another.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2024-10-17 21:13:16 | Re: Avoiding superfluous buffer locking during nbtree backwards scans |
Previous Message | Jacob Champion | 2024-10-17 20:55:59 | Re: doc: virtual envs with Pl/Python |