From PEP 394
https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers
In cases where the script is expected to be executed outside virtual environments,
developers will need to be aware of the following discrepancies across platforms and installation methods:
Older Linux distributions will provide a python command that refers to Python 2, and will likely not provide a python2 command.
Some newer Linux distributions will provide a python command that refers to Python 3.
Some Linux distributions will not provide a python command at all by default, but will provide a python3 command by default.
When potentially targeting these environments, developers may either use a Python package installation tool that rewrites shebang lines
for the installed environment, provide instructions on updating shebang lines interactively,
or else use more specific shebang lines that are tailored to the target environment.
On High Sierra and Mojave, virtualenv 16.x does not build when used with
system Python
Fall back to an older virtualenv version, which is known to work.
Since ENV filtering became the default this has been chucking
erroneous warnings from both `brew doctor` and things like `brew install pygobject`
about needing to run:
```
echo 'import site; site.addsitedir("/usr/local/lib/python2.7/site-packages")' >> /Users/xyz/Library/Python/2.7/lib/python/site-packages/homebrew.pth
```
even though I had Homebrew's `python` installed.
Deprecate more methods. Internal APIs have been verified to be unused
elsewhere and removed. External APIs have had deprecation methods added.
Existing deprecations have been either upgraded to produce warnings or
no longer deprecated and the reasoning documented.
`virtualenv_install_with_resources` will now attempt to guess the
desired Python based on the active build options and based on the
dependencies and requirements. When the situation is ambiguous (e.g.,
`depends_on :python3` and `build.with? "python"` is true) raise
`FormulaAmbiguousPythonError` unless `:using => "python"` or
`:using => "python3"` has been passed to resolve the ambiguity.
In most cases, this will allow
```
virtualenv_create(libexec, "python3")
virtualenv_install_with_resources
```
to be changed to just
```
virtualenv_install_with_resources
```
`any?` is not the opposite of `empty?`. Besides the case that
`[false, nil].any?` will return false, `any?`(O(n)) has much worse
performance than `empty?`(O(1)).
* python: tweak script linking in virtualenv
Instead of making the formula author use a slightly awkward block like
venv.link_scripts(bin) { venv.pip_install buildpath }
avoid exposing this implementation detail and offer the more familiar:
venv.pip_install buildpath, :link_scripts => bin
* Add non-block form and use instead of recursion
* Update 'pip_install' documentation
* Remove obsolete 'link_scripts'
* Add test for 'pip_install' with linking scripts
Also drop no longer relevant (and broken) `link_scripts` test, that
served as a template for the new test.
* Restore compatibility with Ruby 1.8.7
* Replace option hash with 'pip_install_and_link'
* Avoid confusing 'Object#tap' and fix silly bug
* Avoid side effects in mock object parameter check
* Simplify argument check (no need for a block)
Substitue each Version.new and HeadVersion.new with Version.create
to unify Version and HeadVersion instantiation among core code.
Note that this does not relate to Mac::OS::Version class.
Add a helper like std_cmake_args that returns the correct incantation
for invoking setup.py in a consistent way and with our preferred
arguments. Replaces setup_install.
