Re: [pgadmin-hackers] [pgAdmin4] [PATCH] Simplify Server's python setup - Mailing list pgadmin-hackers

From Dave Page
Subject Re: [pgadmin-hackers] [pgAdmin4] [PATCH] Simplify Server's python setup
Date
Msg-id CA+OCxoxMySiZifxtoSbGo-aShWCWwFKFvqH67gt9c2GQsg4XzQ@mail.gmail.com
Whole thread Raw
In response to [pgadmin-hackers] [pgAdmin4] [PATCH] Simplify Server's python setup  (Jan Alexander Steffens <jan.steffens@gmail.com>)
Responses Re: [pgadmin-hackers] [pgAdmin4] [PATCH] Simplify Server's python setup  (Jan Alexander Steffens <jan.steffens@gmail.com>)
List pgadmin-hackers
On Wed, Jan 25, 2017 at 1:43 PM, Jan Alexander Steffens
<jan.steffens@gmail.com> wrote:
> On Wed, Jan 25, 2017 at 12:39 PM Dave Page <dpage@pgadmin.org> wrote:
>>
>> As far as I can see, this breaks usage in development environments, or
>> any configurations where the Python code may be separated from the
>> runtime. Am I missing something?
>
>
> What kind of setup are you talking about? It's not clear to me.

One where the virtualenv is in a path that's not related to the
location of the runtime. If I'm reading the code correctly, you're
taking the appDir (the location of the runtime executable) and
appending a platform-specific path to the virtual env (e.g. on Linux,
"/../venv/bin/"), and expecting to find the Python executable in the
resulting directory.

However, in a dev environment, we may have the venv in
~/.virtualenvs/pgadmin4 and the runtime in
~/git/pgadmin4/runtime/<builddir> for example. In an RPM based
installation, there is no virtualenv - the Python code is installed in
the system site-packages directory, and the runtime in /usr/bin (which
may or may not be where python is found - assuming it's called that,
and not python3).

> If the venv doesn't exist, the program name becomes "/python" and you get
> the standard environment including whatever packages you installed with "pip
> install" or "pip install --user".
>
> Granted, "/python" is nonsense and should probably just be "python". Also, I
> think PATH doesn't need to be touched at all anymore, so the lines involving
> pathEnv can be removed.
>
> How about a settings key to force the program name? That would allow
> choosing any other virtualenv to run with.

That might be a better option, and is basically how (for example)
Pycharms does it. In that case I'd argue that we should search
relative known locations first (such as the installers on Windows/Mac
would lay down), and then fall back to the configured Python
executable. That would allow installed copies to remain independent of
development copies. The only possible wrinkle would be whether a
relocatable installation such as the aforementioned installers would
be able to find their environments based purely on the executable
name.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgadmin-hackers by date:

Previous
From: Jan Alexander Steffens
Date:
Subject: Re: [pgadmin-hackers] [pgAdmin4] [PATCH] Simplify Server's python setup
Next
From: Jan Alexander Steffens
Date:
Subject: Re: [pgadmin-hackers] [pgAdmin4] [PATCH] Simplify Server's python setup