I'm out of ideas. I don't use ansible, don't use certbot on macOS and is well-served by stock ppa:certbot/certbot on Ubuntu (do people actually serve from macOS?), and don't use plugins with mitmproxy, so constructive advice I can give is limited.
Anyway, I find the virtualenv approach much more pleasant than [this](https://github.com/Homebrew/homebrew-core/blob/17a2c4b730ef5cc9023d543dbb6e2a3bbbd59871/Formula/snakemake.rb#L68-L80) for programs that don't require extensibility. Going back seems backwards.
From Homebrew/brew#344,
> Another is PYTHONPATH propagates to child processes, which makes it difficult for a script installed with python2 to launch another script written in python3, since the Python 2 packages in PYTHONPATH may be incompatible. This has been a problem for e.g. Ansible.
Wow I didn't think of this, this is retarded. Goes to show ansible should be run in a controlled environment where shebangs of plugins are absolute, or you'll have problems left and right. Maybe in docker.
By the way I sure as hell ain't advocating putting `/usr/local/lib/python2.7/site-packages` in `PYTHONPATH`; that's horrendous. Ansible plugins should be installed to a prefix exclusive to ansible, mitmproxy plugins should be installed to a prefix exclusive to mitmproxy, etc.
> If they set PYTHONPATH to /usr/local/lib/python2.7/site-packages:$PYTHONPATH in their environment, doesn't that break all of our virtualenv stuff using python3?
Yes, it should be set on a per-program basis, like `alias ansible='PYTHONPATH=... ansible'`. Of course it's not ideal, so for ansible not using virtualenv is fine. However, as I pointed out above, not using virtualenv doesn't actual solve the whole problem (for ansible), it's still there.
Regarding this particular package, by the way, I'm trying to convince my friend to drop the single `requests` dependency, so it may not matter in the end.
@ilovezfs I understand the struggle here, but the pre-virtualenv way isn't the perfect solution, and it's even more limiting in a way.
With the virtualenv way, sure, user plugins are usually out of the way, but I'm surprised that no one ever asked users to set their own `PYTHONPATH` (say, to `/usr/local/lib/python3.6/site-packages:$PYTHONPATH`) pointing to wherever the plugins are installed, which is respected by virtualenv. It's like setting a `PLUGINS_PATH` env var — not that unreasonable.
In contrast, the pre-virtualenv way (without modifications) hardcodes `PYTHONPATH` due to `env_script_all_files `. The python used is hardcoded as `/usr/local/opt/python3/bin/python3.6`, so the places where the user could install their plugins, without custom .pth configurations, are limited to `/usr/local/lib/python3.6/site-packages` and `~/Library/Python/3.6/lib/python/site-packages` (framework build; `~/.local/lib/python3.6/site-packages` for non-framework build). In general, a monolithic dependency tree like this for the entire system is asking for trouble; it goes against our spirit too.
Basically, the difference between the two approaches is that the virtualenv approach intentionally doesn't tap into the system site (but it can if the user asks it to), where things shouldn't be installed to anyway (but in reality people do install stuff there, sigh). Also, currently the pre-virtualenv approach hardcodes `PYTHONPATH` and makes expansion impossible, but that could be changed.
> Homebrew/brew#3167
The ansible problem is hard to solve, it's an intrinsic problem with their sloppy subprocess invocation (I do understand the invoked scripts may not be in Python, making it hard to use `sys.executable`). Switching from a virtualenv python to `/usr/local/bin/python` may appear to solve the problem, but wait until `/usr/local/bin/python` is not the first Python on your PATH — bam, same problem with the subprocess. It's unfair to attribute this problem to virtualenv.
> Little Snitch
This is a python3 package so the python is unsigned either way. (On a personal note, code signing bullshit is th e only thing I hate about LS4; it has given me nothing but headaches.)