Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#392 closed defect (invalid)

sys.exec_prefix does not point to folder with pythonw.exe thus introducing inconsistency,e.g. with multiprocessing in QGIS plugins

Reported by: mlt Owned by: osgeo4w-dev@…
Priority: major Component: Installer
Version: Keywords: python
Cc:

Description

Multiprocessing python module on Windows platform relies on starting a new process as that platform lacks fork(). Head-on attempt to use that module from, e.g, QGIS plugin results in a launch of another QGIS instance. To circumvent this, multiprocessing documentation suggest to use

set_executable(os.path.join(sys.exec_prefix, 'pythonw.exe'))

however pythonw.exe is shipped in bin/ and not in apps/Python27/ where exec_prefix points to.

Change History (5)

comment:1 Changed 6 years ago by jef

Hm, just a suggestion. On Linux it's /usr, which also wouldn't work. Anyway, searching PATH would work.

comment:2 in reply to:  1 ; Changed 6 years ago by mlt

Resolution: invalid
Status: newclosed

Replying to jef:

Hm, just a suggestion. On Linux it's /usr, which also wouldn't work. Anyway, searching PATH would work.

There is no reason to call set_executable() on GNU/Linux as multiprocessing uses fork() on this platform.

Well, perhaps it was an impulsive decision to file this issue. The main point was that current file system layout does not match typical one on this platform and contradicts the manual on multiprocessing. Although the manual says some thing like. I guess it is not a big deal to write

path = os.path.abspath(os.path.join(sys.exec_prefix, '../../bin/pythonw.exe'))
multiprocessing.set_executable(path)

as long as it won't change.

comment:3 in reply to:  2 ; Changed 6 years ago by jef

Or multiprocessing.set_executable(distutils.spawn.find_executable("pythonw.exe"))

comment:4 in reply to:  3 ; Changed 6 years ago by mlt

Replying to jef:

Or multiprocessing.set_executable(distutils.spawn.find_executable("pythonw.exe"))

I wonder if there is a danger to pick up wrong python this way as there are common scenarios to have a few python installations and non-OSGeo4W may be on the PATH.

comment:5 in reply to:  4 Changed 6 years ago by jef

Replying to mlt:

I wonder if there is a danger to pick up wrong python this way as there are common scenarios to have a few python installations and non-OSGeo4W may be on the PATH.

OSGeo4W starts off a clean path. So unless you explicitly add your pythons into PATH from within OSGeo4W you should be fine.

Note: See TracTickets for help on using tickets.