PyPy changed home from bitbucket to foss.heptapod recently[1]. The old
links on bitbucket no longer works. -> Update bitbucket links to their
correspondents on foss.heptapod.net .

[1] https://morepypy.blogspot.com/2020/02/pypy-and-cffi-have-moved-to-heptapod.html

PyPy2 implements -OO differently compared to CPython and it breaks zope.interfaces
at import time: https://foss.heptapod.net/pypy/pypy/-/issues/3356.

- Teach gpython and pymain about `-`;
- Teach gpython and pymain about -O;
- Teach pymain to always set sys.executable, so that subprocess and multiprocessing work correctly out of the box;
- Fix ./bin/gpython crash;
- Rewrite options parsing via incremental getopt-like thing.

This changes are motivated by slapos!862 (comment 121470) and slapos!862 (comment 121600).

/reviewed-by @jerome
/reviewed-on !10

Reported by @jerome here:
slapos!862 (comment 121738)

Let's teach gpython and pymain about -O because buildout calls `python -O`
to byte-compile python sources in optimized mode:

slapos!862 (comment 121470)

When seeing -O, we take the approach to reexecute underlying python with
-O, so that e.g.

	gpython -O file.py

becomes executed as

	python -O gpython file.py

This ensures correctness. The same approach could be used to implement
support for e.g. -S and other low-level options.

An earlier attempt to implement -O without reexecution can be seen at

!7

together with list of problems that arise via that way.

Original idea to reexecute itself come from @jerome.

There was an assert because sys.path[0] is setup as realpath (real, not
relative), but if exe was given as relative path it was raising like
below:

    gpython/gpython_test.py::test_pymain_run_via_relpath GPython 0.0.7.post1 [gevent 20.9.0] / CPython 3.8.6
    Traceback (most recent call last):
      File "./__init__.py", line 482, in <module>
        main()
      File "./__init__.py", line 366, in main
        pymain(argv, init)
      File "./__init__.py", line 82, in pymain
        raise RuntimeError('pymain: internal error: sys.path[0] was not set by underlying python to dirname(exe):'
    RuntimeError: pymain: internal error: sys.path[0] was not set by underlying python to dirname(exe):

            exe:    ./__init__.py
            sys.path[0]:    /home/kirr/src/tools/go/pygolang-master/gpython
    FAILED

-> Fix it by setting up exe as realpath.

This is generic step and should be done under both gpython and standard
python. Handling sys.executable inside pymain offloads users from
setting up sys.executable by themselves, e.g. as in here:

https://lab.nexedi.com/nexedi/slapos/blob/46ed2afe/component/pygolang/buildout.cfg#L39-43

In other words pymain now requires to be passed in full argv when
called. We will need exe=argv[0] in a followup patch to be able to
reexecute underlying python interpreter when given options like -O, -S,
etc...

This is change in behaviour and in general must come with changing
pymain name - e.g. to pymain2 - so that old pymain continues to work as
before. However since there are not so many known pymain users, we can
probably do this change in place since we'll care ourselves about all
those users:

- [python-interpreter] in SlapOS:
  https://lab.nexedi.com/nexedi/slapos/blob/46ed2afe/component/pygolang/buildout.cfg#L30-53

- pyruntraced in Go123:
  https://lab.nexedi.com/kirr/go123/blob/96046edf/tracing/cmd/pyruntraced

- zobjtrace in ZODB:
  https://lab.nexedi.com/kirr/ZODB/blob/07c21671/zobjtrace

So I hope it is ok.

Python allows multiple single-letter options and their arguments to be
coming on single argument, for example:

	python -OQc'print 1'
	python -OQc 'print 1'
	python -OQ -c 'print 1'
	etc...

We are currently trying to handle that at every option, but even though
it kind of works, it is limited and will break once we will start adding
options.

-> Refactor options parsing into getopt-style helper. We cannot use
getopt itself because it will complain e.g. on `gpython file.py
--my-custom-opt` that my-custom-opt is unexpected.

follow up of 64088e8a (gpython: Don't inherit __future__ when executing
scripts, 2020-11-26)

/reviewed-by @kirr
/reviewed-on nexedi/pygolang!9

Because we use execfile to emulate "python script.py" invocation, future
enabled in gpython main script are also enabled in "script.py" and because
we use print_function feature, it was also applied in "script.py".
On python 2 when "script.py" uses print statements they were considered as
SyntaxError.

Hopefuly, compile has a `dont_inherit` flag which does exactly what we need
here: compile the script without inheriting futures enabled, so we use
compile with this flag.

/reviewed-by @kirr
/reviewed-on nexedi/pygolang!8

Nxdtest[1] is tox-like tool to run tests under Nexedi testing
infrastructure.

[1] https://lab.nexedi.com/nexedi/nxdtest

/cc @jerome, @gabriel
/reviewed-on !6

With buildout raw underlying python interpreter does not have access to
eggs with which gpython script was generated. See previous commit for
details.

When buildout generates scripts, it injects the following prologue for
them:

   #!/path/to/underlying/python

   import sys
   sys.path[0:0] = [
     'path/to/egg1',
     'path/to/egg2',
     ...
   ]

   import SCRIPT
   SCRIPT.main()

This way path to eggs are inserted before what was originally
sys.path[0] and it breaks gpython check that `sys.path[0] == exedir`.

-> Fix it by detecting buildout and in that case verifying that exedir
is only present in sys.path, not located in sys.path[0].

We were appending whole $PYTHONPATH to pathv - a vector of path.
But we should instead first split $PYTHONPATH by pathsep and extend pathv.

It is os.pathsep, which is ';' on Windows.

This continues 6b4990f6 (gpython: Fix pymain to properly setup
sys.path[0]) - now we add test and verify that gpython actually sets
sys.path in the same way as underlying python does:

- don't add directory of gpython to sys.path
- for `gpython file` add to sys.path[0] realpath(dir(file)) instead of
  dir(file)  (see PySys_SetArgvEx for the reference, and else - if we do
  not make this change - added test breaks)
- for `gpython -m mod` add to sys.path[0] realpath('') instead of ''.
  This exactly matches PY3 behaviour, while PY2 behaviour is to add ''
  However PY3 behaviour

    * is more sane, and
    * fixes test_defer_excchain_traceback on py27-gevent

  -> so we stick to it.

Now all tests pass again.

GPython preimports golang and gevent, but until now, it was preimporting
them before adjusting sys.path according to given -c/-m/file/... And
this was leading to difference in behaviour with standard Python where
e.g. `import golang` might result in different files loaded if e.g.
golang/ is there on cwd and -c/-m was given.

-> Rework gpython startup so that golang/gevent preimport happens after
sys.path initialization.

This fixes `tox -e py27-gevent` which was previously failing on
test_defer_excchain_dump_pytest / test_defer_excchain_dump_ipython
because dumped paths were different than expected ones.

It, however, breaks test_defer_excchain_traceback on py27-gevent.  ->
We'll do more fixups to sys.path handling in the next patch which will
fix that failure as well.

We'll need this in the next patch, where golang/gevent preimport will be
moved from "before call to pymain", to "in between option parsing and
interpreter start".

There, with pytest 6.0.x, pytest emits its internal deprecation warning
(the usage of deprecated attribute is inside pytest):

    .../_pytest/compat.py:340: PytestDeprecationWarning: The TerminalReporter.writer attribute is deprecated, use TerminalReporter._tw instead at your own risk.
    See https://docs.pytest.org/en/stable/deprecations.html#terminalreporter-writer for more information.
      return getattr(object, name, default)

Which leads to test_defer_excchain_dump_pytest failure since this test
verifies stderr to be empty:

        def test_defer_excchain_dump_pytest():
            tbok = readfile(dir_testprog + "/golang_test_defer_excchain.txt-pytest")
            retcode, stdout, stderr = _pyrun(["-m", "pytest", "-o", "python_functions=main",
                                        "--tb=short", "golang_test_defer_excchain.py"],
                                        cwd=dir_testprog, stdout=PIPE, stderr=PIPE)
            assert retcode != 0, (stdout, stderr)
    >       assert stderr == b""
    E       AssertionError: assert b'/home/kirr/...e, default)\n' == b''
    E         Full diff:
    E         - b''
    E         + (
    E         +  b'/home/kirr/src/tools/go/py3dbg.venv/lib/python3.8/site-packages/_pytest/comp'
    E         +  b'at.py:340: PytestDeprecationWarning: The TerminalReporter.writer attribute i'
    E         +  b's deprecated, use TerminalReporter._tw instead at your own risk.\nSee htt'
    E         +  b'ps://docs.pytest.org/en/stable/deprecations.html#terminalreporter-writer for'...
    E
    E         ...Full output truncated (3 lines hidden), use '-vv' to show

-> Fix it by not letting spawned pytest to emit deprecation warnings in that test.

We'll need warnings control in the next patch to fix Pytest integration
wrt python3-dbg with `-W ignore::DeprecationWarning`.

Reorganize parsiong of command line options so that first all options are
parsed in a loop, and only after that a module/file/command is executed.

This is needed as preparatory step for next patch: there we'll add
support for -W, and `-W arg` can be given multiple times and has to be
processed multiple times by creating multiple corresponding warning
filters. Because those warning filters has to be applied uniformly to
all 4 codepaths of execution phase (-m/-c/file/interactive console), it
makes sense to move execution phase to after options parsing and inject
common runtime preparatory steps right before that.

This logic generally applies not only to -W, but to all other python
options - e.g. -Q,-u,...

Current Debian testing builds libtsan/libasan with --as-needed, which
leads to libstdc++.so not being linked in. Compare Debian 10:

    kirr@link:~/src/tools/go/pygolang$ ldd /usr/lib/x86_64-linux-gnu/libasan.so.5
        linux-vdso.so.1 (0x00007ffe7e97f000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f00ad9d5000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f00ad9cb000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f00ad9aa000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f00ad7d2000)		<-- libstdc++
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f00ad64f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f00ad48e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f00ad472000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f00ae7c8000)

to Debian testing:

    kirr@deco:~/src/tools/go/pygolang$ ldd /usr/lib/x86_64-linux-gnu/libasan.so.6
        linux-vdso.so.1 (0x00007ffe15d0b000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f53ba069000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f53ba047000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f53b9f03000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f53b9d3e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f53b9d24000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f53baa6b000)

where libstdc++ is not being linked to libasan.so

This leads to the following crash:

    golang/golang_test.py::test_pyx_select_inplace ==181237==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_interceptors.cpp:333 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)
        #0 0x7f76aa9f4657  (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xb2657)
        #1 0x7f76aaa11d5a  (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xcfd5a)
        #2 0x7f76aa97ac14 in __cxa_throw (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x38c14)
        #3 0x7f76a497a9ef in panic golang/runtime/libgolang.cpp:79
        #4 0x7f76a497e9a9 in _chanselect golang/runtime/libgolang.cpp:956
        #5 0x7f76a455573c in select<1> golang/libgolang.h:535
        #6 0x7f76a454fa4b in _test_select_inplace() golang/runtime/libgolang_test.cpp:417
        #7 0x7f76a452781e in __pyx_pf_6golang_12_golang_test_30test_select_inplace golang/_golang_test.cpp:4859
        #8 0x7f76a45277db in __pyx_pw_6golang_12_golang_test_31test_select_inplace golang/_golang_test.cpp:4821

explained by https://github.com/google/sanitizers/issues/934

-> work it around by manually preloading libstdc++ as well.

test_defer_excchain_dump_ipython was setting fresh env anew, thus not
propagating $LD_PRELOAD that trun sets when libgolang was built with
thread or address sanitizer. This way the subprocess spawned for IPython
was failing with e.g.

        ==152924==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

-> Fix it by only adjusting environment for spawned IPython instead of
setting it completely anew.

Fixes: 09629367 (golang: tests: Add tests for IPython and Pytest
integration patches)

For example if test_defer_excchain_dump_ipython fails the output was:

    >       assert retcode == 0
    E       assert 1 == 0

and it was unclear what was going on. Now the output is e.g.

    >       assert retcode == 0, (stdout, stderr)
    E       AssertionError: ('', '==152924==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
    E         ')
    E       assert 1 == 0

Amends: 09629367 (golang: tests: Add tests for IPython and Pytest
integration patches) and bb9a94c3 (golang: Teach defer to chain
exceptions (PEP 3134) even on Python2).

Until now gpython was always activating gevent on startup + adding
goodness such as "always UTF-8 default encoding"; go, chan, b/u and
friends available from builtin namespace, etc... While those goodness
are sometimes useful on their own, it is not always appropriate to force
a project to switch from threads to gevent.

For this reason add a flag to select which runtime - either gevent
or threads - gpython should use.

	gpython -Xgpython.runtime=gevent	selects gevent,

while

	gpython -Xgpython.runtime=threads	selects threads.

Gevent remains the default.

It is also possible to specify desired runtime via $GPYTHON_RUNTIME
environment variable.

/reviewed-on nexedi/pygolang!5

Restructure code a bit to prepare it for the next patch.
Plain code movement.

/reviewed-on nexedi/pygolang!5

On CPython:

	$ python -V
	Python 2.7.18

	$ gpython -V
	GPython 0.0.6.post2 [gevent 20.6.2] / CPython 2.7.18

On PyPy:

	$ python -V
        Python 3.6.9 (2ad108f17bdb, Apr 07 2020, 02:59:05)
        [PyPy 7.3.1 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]

	$ gpython -V
	GPython 0.0.6.post2 [gevent 20.5.0] / PyPy 7.3.1 / Python 3.6.9

/reviewed-on nexedi/pygolang!5

And same for -m<module> - becuase Python supports it this way.

Before the patch:

	$ python '-cprint "hello world"'
	hello world
	$ gpython '-cprint "hello world"'
	unknown option: '-cprint "hello world"'

After the patch:

	$ python '-cprint "hello world"'
	hello world
	$ gpython '-cprint "hello world"'
	hello world

/reviewed-on nexedi/pygolang!5

	kirr@deco:~$ python3.8 -v
	import _frozen_importlib # frozen
	import _imp # builtin
	import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
	import '_warnings' # <class '_frozen_importlib.BuiltinImporter'>
	import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
	import '_frozen_importlib_external' # <class '_frozen_importlib.FrozenImporter'>
	import '_io' # <class '_frozen_importlib.BuiltinImporter'>
	import 'marshal' # <class '_frozen_importlib.BuiltinImporter'>
	import 'posix' # <class '_frozen_importlib.BuiltinImporter'>
	import _thread # previously loaded ('_thread')
	import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
	import _weakref # previously loaded ('_weakref')
	import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
	# installing zipimport hook
	import 'time' # <class '_frozen_importlib.BuiltinImporter'>		<-- NOTE
	import 'zipimport' # <class '_frozen_importlib.FrozenImporter'>
	# installed zipimport hook

See https://github.com/python/cpython/commit/79d1c2e6c9d1 for details
(`import time` in zipimport.py)

https://github.com/gevent/gevent/issues/1461 was fixed in
https://github.com/gevent/gevent/commit/cc7e28cf

Gevent is major component gpython builds on - it deserves to be included
into version and is handy to know if one hits a bug with gpython - to
see in which particular runtime environment the bug was hit.

Before:

    $ gpython
    Python 3.7.3 (default, Dec 20 2019, 18:57:59)
    [GCC 8.3.0] [GPython 0.0.6.post2] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    (InteractiveConsole)
    >>>

After:

    $ gpython
    Python 3.7.3 (default, Dec 20 2019, 18:57:59)
    [GCC 8.3.0] [GPython 0.0.6.post2] [gevent 20.5.1] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    (InteractiveConsole)
    >>>

/cc @gabriel, @jerome
/proposed-for-review-on: nexedi/pygolang!4

Add tests for patches to third-party software that were added in
nexedi/pygolang@bb9a94c3.

/cc @gabriel, @jerome
/reviewed-on: nexedi/pygolang!2

This makes recovered exception object a good target to be explicitly
chained into (PEP 3134) via .__cause__ because without .__traceback__ the
information about where/how recovered exception originated would be lost.

In turn, having recover to always return full exception info, should
allow to use recover in "add error context"-style utilities.

/reviewed-on: nexedi/pygolang!3

Starting from setuptools-dso 1.7 pyx.build no longer misses to
(re)compile dsos when `build_ext -i` is run:

https://github.com/mdavidsaver/setuptools_dso/pull/10
https://github.com/mdavidsaver/setuptools_dso/commit/84e06348

Previously `pip install -e` would just fail when run afresh because DSOs
were not built, and so link ext->dso was failing.

bb9a94c3 (golang: Teach defer to chain exceptions (PEP 3134) even on
Python2) added integration patches for IPython and Pytest to properly
dump tracebacks for chained exceptions even on Python2. However the
functionality of patches was tested only manually.

-> Add corresponding tests to verify how IPython and Pytest behaves
when dumping tracebacks.