This is an archive of the discontinued Mercurial Phabricator instance.

pyoxidizer: add user-site to `sys.path` on Windows
ClosedPublic

Authored by mharbison72 on Aug 18 2021, 10:47 PM.

Details

Summary

This is a port of 53221078e0de to Windows to allow pip-installed extensions to
be loaded without specifying a path. It's a major headache to have an hg.exe on
PATH that needs to have the path to the extensions specified, because WSL
doesn't see the same path.

This is only for Windows for now, to match the currently shipping py2 behavior.
There is a better solution with using the site package, but this needs support
in PyOxidizer[1].

[1] https://github.com/indygreg/PyOxidizer/issues/430

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

mharbison72 created this revision.Aug 18 2021, 10:47 PM

This looks good (i.e. similar to what is done in the ./hg script).

Do you think we could get a test for that in test-extensions ? (using a fake APPDATA for that part of the test) ?

This looks good (i.e. similar to what is done in the ./hg script).
Do you think we could get a test for that in test-extensions ? (using a fake APPDATA for that part of the test) ?

I haven't quite got the test working yet (should foo.py in site-packages be loadable, or does it need a directory with __init__.py?). But I see that site.getuserpackages() is available on py3, and it would be easier to write a test against that with support for all platforms. But that should (probably?) go on default, especially since the non pyoxidizer path needs to be updated to stay in sync. So how about this for stable, and a rework on default that supports py3 everywhere.

This looks good (i.e. similar to what is done in the ./hg script).
Do you think we could get a test for that in test-extensions ? (using a fake APPDATA for that part of the test) ?

I haven't quite got the test working yet (should foo.py in site-packages be loadable, or does it need a directory with __init__.py?). But I see that site.getuserpackages() is available on py3, and it would be easier to write a test against that with support for all platforms. But that should (probably?) go on default, especially since the non pyoxidizer path needs to be updated to stay in sync. So how about this for stable, and a rework on default that supports py3 everywhere.

You mean getting this specific patch for stable, without a test, and a more complete version for default, with a test ?

That would work for me.

This looks good (i.e. similar to what is done in the ./hg script).
Do you think we could get a test for that in test-extensions ? (using a fake APPDATA for that part of the test) ?

I haven't quite got the test working yet (should foo.py in site-packages be loadable, or does it need a directory with __init__.py?). But I see that site.getuserpackages() is available on py3, and it would be easier to write a test against that with support for all platforms. But that should (probably?) go on default, especially since the non pyoxidizer path needs to be updated to stay in sync. So how about this for stable, and a rework on default that supports py3 everywhere.

You mean getting this specific patch for stable, without a test, and a more complete version for default, with a test ?

Yes

This looks good (i.e. similar to what is done in the ./hg script).
Do you think we could get a test for that in test-extensions ? (using a fake APPDATA for that part of the test) ?

I haven't quite got the test working yet (should foo.py in site-packages be loadable, or does it need a directory with __init__.py?). But I see that site.getuserpackages() is available on py3, and it would be easier to write a test against that with support for all platforms. But that should (probably?) go on default, especially since the non pyoxidizer path needs to be updated to stay in sync. So how about this for stable, and a rework on default that supports py3 everywhere.

You mean getting this specific patch for stable, without a test, and a more complete version for default, with a test ?

Yes

That sounds good!

Alphare accepted this revision.Aug 25 2021, 5:59 AM
This revision is now accepted and ready to land.Aug 25 2021, 5:59 AM
This revision was automatically updated to reflect the committed changes.