I do not understand what the intended side-effect of running this command is supposed to be.

This is a dupe of D8339.

As scary as this patch sounds, I'm pretty sure it is safe, as I believe it restores compatibility with Python 2. Changing sys.std* to be binary streams instead of text streams would be a bigger BC break. And that is not a change I want to make, as this would invalidate assumptions in 3rd party code about the behavior of these streams on Python 3!

This commit isn't strictly required. I performed this refactoring anticipating needing to add sys.std* fixups as part of this function. But it turns out that the SSH protocol server handles I/O redirection via a different mechanism. There actually appear to be redundant mechanisms for intercepting stdio as part of the wire protocol. This is potentially an area that we could clean up. But I'm not inclined to do so at this time.

@yuja I'd appreciate your eyes on this since you have a firm grasp on Windows/Unicode matters...

To clarify, bundle specifications are user-facing whereas changegroup versions are an internal implementation detail. Their version numbers are thus on different timelines and aren't strictly related.

This simply tells PyOxidizer to load the sys.meta_path importer that performs filesystem-based importing, like a normal Python process. https://pyoxidizer.readthedocs.io/en/stable/config_api.html#pythoninterpreterconfig

macOS supports a @loader_path and related magic tokens in rpath to load libraries relative to the current binary. See e.g. https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os and https://medium.com/@donblas/fun-with-rpath-otool-and-install-name-tool-e3e41ae86172 for examples.

OK. If an upgraded install works, I'm happy with landing this. We might as well land all the larger installer refactorings in this release. That should set us up for hopefully a less invasive switch to Python 3, as the install layouts will already be mostly identical.

Did you test an upgrade over an existing install with this? My recollection is the case collision caused issues in my local testing, which is why I preserved the case difference between the installers.

As a follow-up, we can likely merge the requirements.txt[.in] files now.

In D7173#118947, @mharbison72 wrote:

This change also means that Inno and WiX are now using very similar code for managing the install layout. This means that on disk both packages are nearly identical. The differences in install layout are as follows:
...

I diffed the WiX and Inno installs side by side, and there are a few more differences right before the 5.3 release. I don't think there's anything critical, but just in case there could be an issue:

• Inno installs backports.configparser, certifi, dulwich, keyring, urllib3, and win32ctypes in library.zip.

I just released PyOxidizer 0.5.0 and have updated the instructions in this file accordingly.

I don't have strong opinions about bundling templates and other resources internally versus externally. I do think it would be cool to have a fully self-contained executable. But that would require a command to write out embedded resources to the filesystem so people can modify them. That's a bit obscure.

This produces a working hg executable with templates support on Linux and Windows (I haven't tested macOS). I'd feel comfortable landing if it will unblock others to hack on things.

Modern versions of pyoxidizer don't need to vendor the pyembed crate. So abandoning this.

I submitted this series as a PoC. We likely won't move ahead with it. Although if we want to pursue prolonged Python 2.7 support, this series would likely make it easier...

This series is for stable in case it gets missed in the Phabricator UI.

Yeah, it was flagged as stable in the branch metadata. But whoever queued it didn't see that. (Perhaps we should improve hg phabread to warn on branch name mismatch?)