This reworks `Language::Python::Shebang` to use constants for
the shebang regex and max length (like the previous Node commit).
Besides that, this also adds type signatures to the existing methods.
This primarily reworks `Language::Perl::Shebang` to use constants for
the shebang regex and max length (like the previous Node commit) and
to extract the `RewriteInfo` call into a separate method (like Python
and Node).
Besides that, this also adds type signatures to the methods.
Formulae that depend on `node` sometimes contain files that use a
shebang like `#!/usr/bin/env node` and this can lead to issues when
the `node` in a user's environment isn't brewed `node`.
For example, some node modules are compiled when the formula is built
but if the user's `node` is a different major version than brew's
`node`, the differing `NODE_MODULE_VERSION` can produce an error when
certain parts of the application are used. The formula may build and
test fine and the issue may only become apparent when more of the
application is exercised.
This adds a `Language::Node::Shebang` module (borrowing from the
existing Perl and Python examples), which allows us to use
`rewrite_shebang detected_node_shebang, ...` in formulae to address
this type of issue.
Some formulae are flexible about the version of Python3 that they use.
However, when we use `#detected_python_shebang` on these formulae, they
become coupled to the specific version of Python3 declared in the
formula.
This is harmful because
1. it prevents us from using `uses_from_macos "python"` even in formulae
where we should be able to
2. it forces us to rebuild the formula whenever we make changes to the
Python dependency when nothing but the shebang would have changed as
a consequence of the rebuild
For an example of this, see Homebrew/homebrew-core#107905.
I'd also like to do this to get rid of some really terrible hacks we
have in `glib-utils` as a means of decoupling `glib` from the specific
versioned Python dependency it used to have.
See Homebrew/homebrew-core#103916, or Homebrew/homebrew-core#106045 for
a proposal to give the same treatment to `gobject-introspection`.
About 25 formula in homebrew/core pass `--install-lib` to `python3` in
addition to `*setup_install_args` in order to ensure that all files are
installed into the formula's prefix rather than into a `site-packages`
directory in Python's keg.
Let's simplify these formulae by also adding the appropriate
`--install-lib` flag to `setup_install_args`.
A user may wish to use two use two brew-installed Python packages
together. For example, one might want to `import numpy` when using
`jupyterlab` or `ptpython`.
Currently, the only ways to do this I'm aware of is with some hacking of
`PYTHONPATH` or the creation of `.pth` files in a formula's prefix.
A better solution is to allow the virtualenvs that `brew` creates to
have access to system site-packages by default, so that `import numpy`
inside `ptpython` or `jupyterlab` just works.
Partially resolvesHomebrew/homebrew-core#76950.
This reverts commits 318175cfe2b23328f1b5f13812fd59cfd45fe1dc,
e7ab760392b9691a6c730b7e0d660b7874969e70 and
3b35af63f608438b1882756feca94a6ebdd0d6a3 (PR #11537).
