classification
Title: Windows sys.path file should be renamed
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.7, Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: christian.heimes, paul.moore, python-dev, steve.dower, tds333, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2016-09-13 21:07 by steve.dower, last changed 2017-03-31 16:36 by dstufft. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 552 closed dstufft, 2017-03-31 16:36
Messages (9)
msg276343 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-09-13 21:07
The Windows getpath implementation gained the ability to find and read a sys.path file to skip reading the registry.

While the name is cute, it really ought to start with a leading underscore (i.e. "_sys.path") to indicate that it is very at-your-own-risk. The docs should be updated to indicate that its behavior may be changed in later versions of Python (though it's guaranteed to only change backwards-compatibly for 3.6).

Since the file is only used with a specific installation of Python (specifically the embedded distro), this shouldn't be an issue as nobody is meant to upgrade Python without removing/replacing this file.
msg276350 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-13 21:43
I don't want to start a bike-shedding discussion but how about a name that can't be confused with a module and attribute? It's hard to distinguish between sys.path and sys.path in a discussion. How do you like the idea of a file name like __syspath__.path? __omitregistry__.path is even more search engine friendly.
msg276353 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-09-13 22:01
Part of the reason it was so cute is that it directly specifies the contents of sys.path. But I like __syspath__.path (I'm scared of making it a ".ini" because I don't want to parse a more complex format).
msg276551 - (view) Author: Wolfgang Langner (tds333) * Date: 2016-09-15 13:22
If this is only for the use case of embedded distribution we are now only to steps away to provide a easy custom shipping of applications for Windows.

1. Take the file name of the executable to load a custom EXECUTABLENAME.path file
2. Allow to specify a main to be executed or a pyz zipapp to be run with the -m switch. Or simply use first line of the path file if it contains "-m myapp".

With this by only renaming the python.exe and having a simple text file with the information, custom applications distribution can be done.

Sorry, I know not directly related to this.
msg276553 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-09-15 13:58
You can actually handle this already, with a simple wrapper program (based on the one in PC\WinMain.c):

/* Minimal main program -- everything is loaded from the library. */

#include "Python.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

int wmain()
{
    wchar_t **myargv = malloc((__argc + 3) * sizeof(wchar_t*));
    int i;
    myargv[0] = __wargv[0];
    myargv[1] = L"myapp.zip";
    for (i = 1; i < __argc; ++i) {
        myargv[1+i] = __wargv[i];
    }
    myargv[1+i] = 0;
    return Py_Main(__argc+1, myargv);
}

This injects your application name "myapp.zip" as the first argument and then calls the Python main interpreter. Run this with a conventional embedded Python, and you have a standalone application.

You can easily tidy the above sample up (it's just a quick hack) to make it generic by working out the name of the zipped Python application from the exe name.

But thanks for the idea - I hadn't really thought about doing something like this until you prompted me to investigate.
msg276563 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-09-15 15:18
I like it. Making the name match the exe name should have been obvious, and if nobody is opposed to simply aborting on unsupported syntax (i.e. imports other than site) I don't actually mind making it .pth.

It's a separate idea, but what if the presence of a __main__.py file caused that file to always run and every argument gets passed to that instead? The purposes seem separate enough to use two files. And we could implement that part easily enough in PC/WinMain.c, as Paul suggests.

Both of these options are fairly aggressive wrt other command line options (i.e. how do you specify unbuffered IO? how do you set the hash seed?), but the point is really that you wouldn't use them with these options - if you don't want to build your own main() function, the defaults should be good enough.
msg276568 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2016-09-15 15:52
I'd prefer not to hard code __main__.py, as I'd quite like to be able to have a number of copies of the executable, each running its own script. (I foresee putting all my little Python utility scripts in a directory with a Python installation and a set of launchers).

BTW, see https://github.com/pfmoore/pylaunch for a very quickly put together, but working, prototype. Whatever the conclusion here, I'll probably continue working on this. Unless the embedded python.exe completely subsumes the functionality :-)
msg276825 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-09-17 19:57
New changeset 7b47c98f24da by Steve Dower in branch '3.6':
Issue #28137: Renames Windows path file to ._pth
https://hg.python.org/cpython/rev/7b47c98f24da
msg276827 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-09-17 19:58
Decided to go with "DLLNAME._pth" or "EXENAME._pth", since using ".pth" with "import site" causes files to be reevaluated.
History
Date User Action Args
2017-03-31 16:36:25dstufftsetpull_requests: + pull_request992
2016-09-17 19:58:57steve.dowersetstatus: open -> closed
resolution: fixed
messages: + msg276827

stage: needs patch -> resolved
2016-09-17 19:57:27python-devsetnosy: + python-dev
messages: + msg276825
2016-09-15 15:52:22paul.mooresetmessages: + msg276568
2016-09-15 15:18:10steve.dowersetmessages: + msg276563
2016-09-15 13:59:00paul.mooresetmessages: + msg276553
2016-09-15 13:22:20tds333setnosy: + tds333
messages: + msg276551
2016-09-13 22:01:54steve.dowersetmessages: + msg276353
2016-09-13 21:43:58christian.heimessetnosy: + christian.heimes
messages: + msg276350
2016-09-13 21:07:35steve.dowercreate