The main thing is that this DSL allows us to provide an
interface that can be serialized to the JSON API.
Changes:
- Homebrew::Service
- Adds `#service_name` and `#plist_name` methods
- Each is now included in the `#serialize` method as well
- Eval block on instantiation
- Before we lazy evaluated this but the cost is not significant
and it complicated the code a bunch. This only gets called
during install, when evaluating caveats and in the `brew service`
command. It skips this evaluation if the service block isn't there.
- Add `#command?` helper to avoid `#command.blank?` and `#command.present?`
- Formula
- `#service` now returns a service whenever it's called. This call is
hidden behind a call to `#service?` most of the time anyway so this
should be fine.
- `#plist_name` and `#service_name` now call the methods of the same name
on the service class. This should have already been in the service object
to begin with and keeping these methods here helps preserve backwards
compatibility with people who were overwriting these methods before.
- Caveats
- Prefer `service#command?`
- Add helpers for checking on service commands
- This duplicates some of the work in `brew services`. Maybe we should
merge that repo in at some point.
- Check for installed service at `#plist_name` or `#service_name`. I think
this should be used instead of `Keg#plist_installed?` which checked for any plist file.
We should think about deprecating `#plist_installed?` in the future.
- Stop using `ps aux | grep #{formula.plist_name}` to check for service files
because it was inaccurate (it always returns true on my machine) because the grep
process is started before the ps process.
- Note: The behavior is the same as it was before. This means that caveats
only show up for custom service files on install or if they're already installed.
Otherwise it won't show up in `brew info`. This is because it has to check
first if the service file has been installed.
- Utils::Service
- Add utils for evaluating if a service is installed and running. This duplicates
some of the work already found in `brew services`. We should seriously consider
merging `brew services` with the main brew repo in the future since it's already
tightly coupled to the code in the main repo.
- Formulary.load_formula_from_api
- Be more explicit about which types can be deserialized into run params since
it is now possible for run params to be nil.
- Update and add tests
- roll InfluxDB token (we need to report to a new bucket to fix implicit schema)
- adjust various parameters
- separate default tags and fields
- send more fields and fewer tags (tags should have low cardinality)
- use `--data-binary` to match InfluxDB documentation
- document second precision for greater InfluxDB performance
- pass through tap name, formula/cask name, options separately
- pass `devcmdrun` as a tag
- avoid sending very high-cardinality `OS_VERSION` values
- These are arbitrary length limits that had a load of disables in code.
- The limits were only increasing over time rather than decreasing.
- Fixing the problematic code to be shorter would take a long time for
questionable gain since the problem has been around so long.
- We're not going to make the really long things be any shorter any time soon.
- The instructions in issue 14685 say, pragmatically, "disable all the rubocop
rules we're never going to realistically fix e.g. Metrics/ClassLength". But
that felt like a slippery slope to more _really_ long modules/classes/blocks,
and the limits are here for a reason.
We warn sometimes when we tell people to build from source and it's
not supported but we don't actually warn non-developers when invoking
the various install commands so: let's start doing so.
While we're here, also update the existing messaging to reflect the fact
we're on Mastodon now too and we don't want maintainers being
individually bothered about errors either.
I've tried to balance having messages here vs. having them be so long
at the beginning of installation that they will be missed or be overly
obnoxious.
- flip the messaging to refer to `HOMEBREW_NO_INSTALL_FROM_API` where relevant
- remove some duplicate checks
- better scope checks to just core tap formulae
Given a `pkg_a` that depends on `pkg_b`, it is redundant to list
`pkg_b` as a dependency when running the following commands:
- `brew install pkg_b pkg_a`
- `brew upgrade` (when both `pkg_a` and `pkg_b` are outdated)
We're still getting a non-trivial number of issues from configurations
we don't support and don't plan to.
Let people know that we know their experience will not be good and what
to expect if they file issues.
Co-authored-by: Eric Knibbe <enk3@outlook.com>
Right now this is done through the gcc@5 formula.
See 9692318ca6/Formula/gcc%405.rb (L33)
This is fragile because when we will migrate to gcc@11
we have to think about migrating the installation from one gcc formula to another..
Also, not having the right glibc version results in a non-functional brew
installation on an older Linux: the glibc installation needs
to be done by brew, and not by a workaround in a specific formula
Co-Authored-By: Mike McQuaid <mike@mikemcquaid.com>
Co-Authored-By: Bo Anderson <mail@boanderson.me>
Co-Authored-By: Shaun Jackman <sjackman@gmail.com>
