D7450: packaging: add support for PyOxidizer

[mharbison72 (Matt Harbison)]

This revision now requires changes to proceed.
mharbison72 added a comment.
mharbison72 requested changes to this revision.


  I think this can land after the Windows options are added.
  
  > So we don't need to worry about vendoring any Rust code to initially support PyOxidizer.
  
  Does that mean the parent of this can go away?
  
  For anybody else following along, start by updating Rust, especially on Windows.  IDR what version I had and it scrolled off the screen at this point, but I installed it in late October/early November.  Building PyOxidizer 0.5.0 cause my antivirus to go nuts when it was building some dependencies in MSYS.  (Being totally new to Rust, I'm wondering how we know that we can trust the numerous dependencies).  I switched to cmd.exe, and I started getting popups about CRT issues.  Updating seems to have fixed both of these.  (I've got rustc 1.40.0 now.)
  
  It also looks like something creates paths longer than MAX_PATH, which most tools can't deal with.  (I know there's a registry option to enable support globally, but I wonder if `make clean` should be delegating to a tool smart enough to handle long paths)
  
    $ make clean>/dev/null
    'build\lib.win-amd64-2.7' does not exist -- can't clean it
    'build\bdist.win-amd64' does not exist -- can't clean it
    'build\scripts-2.7' does not exist -- can't clean it
    rm: cannot lstat `build/pyoxidizer/python_distributions/python.86a3260edabeed314c6f32a931e60dd097fa854b1346561443353e1bc90e3edd/python/install/Lib/site-packag
    es/pip-19.3.1-py3.7.egg/pip/_vendor/urllib3/contrib/_securetransport/__pycache__/bindings.cpython-37.pyc': File or path name too long
    rm: cannot lstat `build/pyoxidizer/python_distributions/python.86a3260edabeed314c6f32a931e60dd097fa854b1346561443353e1bc90e3edd/python/install/Lib/site-packag
    es/pip-19.3.1-py3.7.egg/pip/_vendor/urllib3/contrib/_securetransport/__pycache__/low_level.cpython-37.pyc': File or path name too long
    rm: cannot lstat `build/pyoxidizer/python_distributions/python.86a3260edabeed314c6f32a931e60dd097fa854b1346561443353e1bc90e3edd/python/install/Lib/site-packag
    es/pip-19.3.1-py3.7.egg/pip/_vendor/urllib3/contrib/_securetransport/__pycache__/__init__.cpython-37.pyc': File or path name too long
    rm: cannot lstat `build/pyoxidizer/python_distributions/python.86a3260edabeed314c6f32a931e60dd097fa854b1346561443353e1bc90e3edd/python/install/Lib/site-packag
    es/pip-19.3.1-py3.7.egg/pip/_vendor/urllib3/packages/ssl_match_hostname/__pycache__/_implementation.cpython-37.pyc': File or path name too long
    rm: cannot lstat `build/pyoxidizer/python_distributions/python.86a3260edabeed314c6f32a931e60dd097fa854b1346561443353e1bc90e3edd/python/install/Lib/site-packag
    es/pip-19.3.1-py3.7.egg/pip/_vendor/urllib3/packages/ssl_match_hostname/__pycache__/__init__.cpython-37.pyc': File or path name too long
    make: *** [cleanbutpackages] Error 1
  
  Another fun thing to handle will be stacktrace differences in tests.  Note the '.' vs '/' separator.  Is this related to the module naming issue that you referenced, and/or the unresolved issues behind the PyOxidizer issue I referenced here earlier?
  
    @@ -646,7 +634,7 @@
     Even though the extension fails during uisetup, hg is still basically usable:
       $ hg --config extensions.baduisetup=$TESTTMP/baduisetup.py version
       Traceback (most recent call last):
    -    File "*/mercurial/extensions.py", line *, in _runuisetup (glob)
    +    File "mercurial.extensions", line 251, in _runuisetup
           uisetup(ui)
         File "$TESTTMP/baduisetup.py", line 2, in uisetup
           1 / 0

INLINE COMMENTS

> pyoxidizer.bzl:25
> +        # We need this to make resourceutil happy, since it looks for sys.frozen.
> +        sys_frozen = True,
> +    )

I'm not sure why this worked for you on Windows, but I also needed to add:

  legacy_windows_stdio = True,
  legacy_windows_fs_encoding = True,

(I'm not sure if fs_encoding is really needed, but that was in the config file I was hacking with back in early December.)  Without the stdio option, I got no output from the `hg config` command.  Maybe because that wants to spin up a pager?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7450/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7450

To: indygreg, #hg-reviewers, mharbison72
Cc: marmoute, mharbison72, martinvonz, durin42, kevincox, mercurial-devel