Re: doc: virtual envs with Pl/Python

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

In response to

Responses

Browse pgsql-hackers by date

  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