- User Since
- Jul 1 2017, 5:02 PM (144 w, 4 d)
Wed, Apr 1
I do not understand what the intended side-effect of running this command is supposed to be.
Tue, Mar 31
Sun, Mar 29
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.
Sat, Mar 28
@yuja I'd appreciate your eyes on this since you have a firm grasp on Windows/Unicode matters...
Feb 28 2020
Feb 26 2020
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.
Feb 15 2020
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
Feb 11 2020
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.
Feb 3 2020
Feb 2 2020
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.
Feb 1 2020
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.
Jan 31 2020
Jan 30 2020
Jan 26 2020
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.
Jan 25 2020
Jan 24 2020
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?)