Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows sys.path file should be renamed #72324

Closed
zooba opened this issue Sep 13, 2016 · 9 comments
Closed

Windows sys.path file should be renamed #72324

zooba opened this issue Sep 13, 2016 · 9 comments
Assignees
Labels
3.7 OS-windows type-bug

Comments

@zooba
Copy link
Member

@zooba zooba commented Sep 13, 2016

BPO 28137
Nosy @pfmoore, @tds333, @tiran, @tjguk, @zware, @zooba
PRs
  • #552
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/zooba'
    closed_at = <Date 2016-09-17.19:58:57.413>
    created_at = <Date 2016-09-13.21:07:35.172>
    labels = ['type-bug', '3.7', 'OS-windows']
    title = 'Windows sys.path file should be renamed'
    updated_at = <Date 2017-03-31.16:36:25.673>
    user = 'https://github.com/zooba'

    bugs.python.org fields:

    activity = <Date 2017-03-31.16:36:25.673>
    actor = 'dstufft'
    assignee = 'steve.dower'
    closed = True
    closed_date = <Date 2016-09-17.19:58:57.413>
    closer = 'steve.dower'
    components = ['Windows']
    creation = <Date 2016-09-13.21:07:35.172>
    creator = 'steve.dower'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 28137
    keywords = []
    message_count = 9.0
    messages = ['276343', '276350', '276353', '276551', '276553', '276563', '276568', '276825', '276827']
    nosy_count = 7.0
    nosy_names = ['paul.moore', 'tds333', 'christian.heimes', 'tim.golden', 'python-dev', 'zach.ware', 'steve.dower']
    pr_nums = ['552']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue28137'
    versions = ['Python 3.6', 'Python 3.7']

    @zooba
    Copy link
    Member Author

    @zooba zooba commented Sep 13, 2016

    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.

    @zooba zooba added the 3.7 label Sep 13, 2016
    @zooba zooba self-assigned this Sep 13, 2016
    @zooba zooba added OS-windows type-bug labels Sep 13, 2016
    @tiran
    Copy link
    Member

    @tiran tiran commented Sep 13, 2016

    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.

    @zooba
    Copy link
    Member Author

    @zooba zooba commented Sep 13, 2016

    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).

    @tds333
    Copy link
    Mannequin

    @tds333 tds333 mannequin commented Sep 15, 2016

    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.

    @pfmoore
    Copy link
    Member

    @pfmoore pfmoore commented Sep 15, 2016

    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.

    @zooba
    Copy link
    Member Author

    @zooba zooba commented Sep 15, 2016

    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.

    @pfmoore
    Copy link
    Member

    @pfmoore pfmoore commented Sep 15, 2016

    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 :-)

    @python-dev
    Copy link
    Mannequin

    @python-dev python-dev mannequin commented Sep 17, 2016

    New changeset 7b47c98f24da by Steve Dower in branch '3.6':
    Issue bpo-28137: Renames Windows path file to ._pth
    https://hg.python.org/cpython/rev/7b47c98f24da

    @zooba
    Copy link
    Member Author

    @zooba zooba commented Sep 17, 2016

    Decided to go with "DLLNAME._pth" or "EXENAME._pth", since using ".pth" with "import site" causes files to be reevaluated.

    @zooba zooba closed this as completed Sep 17, 2016
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.7 OS-windows type-bug
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants