Hi On Wed, Jan 25, 2017 at 2:35 PM, Jan Alexander Steffens <jan.steff...@gmail.com> wrote: > > > On Wed, Jan 25, 2017 at 2:57 PM Dave Page <dp...@pgadmin.org> wrote: >> >> 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). >> >> > 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. > > > I've now implemented this (see attached updated patch) and Python will > configure itself to match whatever usable "python" it finds first in the > PATH, including any activated virtualenv. > > I think the RPM setup will still work properly, as the non-virtual > environment with all system packages is the fallback case. > >> >> > >> > 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. > > > Wouldn't the installed Python on Windows or OSX be caught be the PATH search > Python does, too? Unfortunately I can't test either.
I'll test that as part of a deeper review. In the meantime, I'm thinking something like the attached patch would be more appropriate. The only issue I can find with it at the moment (having just tested on a Mac dev environment for now) is that if initialisation fails and you enter a new Python Executable path, the Py_Finalize()/Py_Initialize cycle isn't enough to make the change - it seems to be because Py_SetProgramName() doesn't have any effect when called again. In other words, you can give it the correct interpreter and hit OK to attempt to run the server again, but it still won't work until you actually restart the app. Any ideas? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
0001-Simplify-Server-s-python-setup-Dave.patch
Description: Binary data
-- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
