Shell detection failure inside docker image on ARM Macbook

We have a docker container, for which we’re running into a shell detection failure:

Traceback (most recent call last):
  File "/opt/conda/bin/verdi", line 8, in <module>
    sys.exit(verdi())
  File "/opt/conda/lib/python3.7/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/opt/conda/lib/python3.7/site-packages/click/core.py", line 777, in main
    _bashcomplete(self, prog_name, complete_var)
  File "/opt/conda/lib/python3.7/site-packages/click_completion/patch.py", line 122, in _shellcomplete
    echo(get_code(prog_name=prog_name, env_name=complete_var))
  File "/opt/conda/lib/python3.7/site-packages/click_completion/core.py", line 299, in get_code
    shell = get_auto_shell()
  File "/opt/conda/lib/python3.7/site-packages/click_completion/lib.py", line 125, in get_auto_shell
    return shellingham.detect_shell()[0]
  File "/opt/conda/lib/python3.7/site-packages/shellingham/__init__.py", line 24, in detect_shell
    raise ShellDetectionFailure()
shellingham._core.ShellDetectionFailure

For some reason, this only happens when running the docker container on M1 Macbooks (on Intel Macbooks, the error in the container does not occur). Observations:

• Shellingham version in container is 1.4.0
• Shellingham 1.4.0 in a local conda environment on my machine detects the shell just fine (tested with both python 3.7 and 3.9)
• Both inside container and on my machine, the detected os.name is posix

For some reason, the shell detection for posix returns None https://github.com/sarugaku/shellingham/blob/325c643e89877eb325adf44bc62547251e87acef/src/shellingham/posix/__init__.py#L82-L90

Steps to reproduce:

1. Own a Macbook M1 (sorry!)

docker run -d -it --name aiida-core aiidateam/aiida-core:1.6.5
docker exec -it --user aiida aiida-core bash

[uranusjr]

Alright I finally have a chance to look into this. So for this specific environment combination (an Intel image running in Docker on ARM Mac), the parent process is (interestingly) hooked to a different TTY from the Python process itself. I suspect this is due to some simulation implementation detail that leaked into the container. So this is “easily” amendable by removing the TTY check, but I’m hesitant to just do that since it makes the proc implementation quite a bit slower.

An alternative approach would be to do some refactoring and make process look up lazier, so we only access process IDs that are related to the current process. I’m not particularly motivated to do this myself (especially considering that setting PIPENV_SHELL is a pretty adequate workaround), but anyone would be much welcomed to contribute to this.

[uranusjr]

Shellingham is never called if you set PIPENV_SHELL, since the variable forces pipenv shell to use that instead of doing any detection. So yeah, you could use that to work around whatever the problem is here.