--preamble runpy path error

I believe this may be an issue on linux machines… but when trying to copy the cleanup example posted in PR #156 exactly, and running with the require flags:

... --preamble shiv_cleanup.py ...

I get the error:

Traceback (most recent call last):
  File "envs/python38/lib/python3.8/runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "envs/python38/lib/python3.8/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "./mpro/__main__.py", line 3, in <module>
  File "./mpro/_bootstrap/__init__.py", line 219, in bootstrap
  File "envs/python38/lib/python3.8/runpy.py", line 262, in run_path
    code, fname = _get_code_from_file(run_name, path_name)
  File "envs/python38/lib/python3.8/runpy.py", line 232, in _get_code_from_file
    with io.open_code(fname) as f:
TypeError: open_code() argument 'path' must be str, not PosixPath

Looks like this is because runpy doesn’t support Path objects? Its failing on 232:

  230 def _get_code_from_file(run_name, fname):
  231     # Check for a compiled file first
  232     with io.open_code(fname) as f:
  233         code = read_code(f)
  234     if code is None:
  235         # That didn't work, so try it as normal source code
  236         with io.open_code(fname) as f:
  237             code = compile(f.read(), fname, 'exec')
  238     return code, fname

As a near term fix, should this pathobj be converted to a string?

[lorencarvalho]

hey @Alex-Mann,

I’ve actually observed this too, on Python 3.8.2 on macOS:

>       assert proc.returncode == 0
E       AssertionError: assert 1 == 0
E        +  where 1 = CompletedProcess(args=['/private/var/folders/rk/3q7k_qzs7mz4w2j44331qyv40005tq/T/pytest-of-lcarvalh/pytest-40/test_pre..._from_file\n    with io.open_code(fname) as f:\nTypeError: open_code() argument \'path\' must be str, not PosixPath\n').returncode

I’d happily ship an RB string-ifying those inputs 😃

[mhucka]

After studying the problem, I found a very simple, one-line fix. PR #196 implements the changes. This makes shiv-produced zipapps work on my version of the Apple-provided Python 3.8 on macOS 10.14 and macOS 11.1 (where I’ve tested so far).

Would the maintainers of shiv please consider incorporating this change?