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`.
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).
/usr/libexec/java_home is specific to macOS.
Language::Java::java_home_cmd is not implemented on Linux and raises
NotImplementedError.
Add private Language::Java::java_home_shell and use it instead of java_home_cmd.
Add public Language::Java::java_home for use by formulae.
- Avoid using a temporary variable where not necessary
- Use fewer, better stubs in the tests to avoid warnings and better
test the implemented functionality.
instead of writing a .npmrc file, which simplifies the code.
npm_cache_config is still preserved for backwarts compatiblility and
usage int he kibana@n formulas in core.
This tells npm pack to don't run prepublish scripts at all.
I think this is the best default because:
* most modules don't have a prepublish script at all and aren't affected
by this change
* most prepublish scripts are calling devDeps, which would fail in our
case, because (dev)Deps aren't installed at npm pack time until #2820
gets resolved
* we favor npm registry tarball for formula downloads, which are already
prepublished, so we would in the best case needlessly run prepublish
a second time and in the worst case it would fail (because a clean
step is required before running prepublish a second time in a row)
* This change does the right thing for >99% of all the packages and
would only affect packages with prepublish scripts downloaded from a
non-npm registry tarball (like github tarballs) and with a prepublish
script wich does no't require any devDep (unlike for cross platform)
By telling node-pre-gyp and prebuild to don't pull prebuild binaries and
instead build them from source. This still may not work for some custom
third party scripts for pulling prebuild binaries.
