This PR introduces the YAML frontend for plaster that is meant to
eventually become the only frontend, once all `.toml` Plaster files are
migrated.
This change covers all places where the assumption about `.toml` files
was being used, inclusing `brockit`, and `git-cr` tools.
Most of the code that should be deleted in the future is well guarded
with comments leading back to the issue tracking, so the TOML parser can
be dropped eventually.
With this change, a dependency to `pyyaml` has been introduced. This
dependency has wheels provided by `vpython`, which is already the
expected python runtime for Plaster.
- Rationale for this change
We have experimented at length with `.toml` files, in order to
understand some of the shortcomings they have that would be addressed
with `.yaml` files.
* `prettier` offers YAML formatting out-of-the-box. On the other hand,
formatters for TOML files are not easy to find, as both `prettier`
and `vpython` have their own challanges with the current options
* YAML's sytanx works better with codeblocks, as it doesn't require
quoting. This makes the content seen less noisy. Looking on some of
the migrated plasters, the YAML substitutions look more readable.
* YAML has better sytanx highlight support in some editors.
Bug: https://github.com/brave/brave-browser/issues/55738
This change adds a dry run mode to plaster, that can be called with:
```sh
tools/cr/plaster.py check
```
This command can also be called with a list of files, that can be either
`rewrite/` files or `patches/` files.
We are also adding support to plaster for .patchinfo files, allowing a
more efficient way to make sure any given plaster file has should be
regenerated.
### What does plaster do to .patchinfo files
Plaster now generates the contents of a .patchinfo file, and based on
that content it determines if one of these files must be updated:
source, patch, or patchinfo (a combination of npm run update_patches
and npm run apply_patches). A new key is being added to the patchinfo
format, namely, plaster, which is used to store the path and checksum
for the plaster file for a given patch/source set. Files are only
updated on disk if the resulting new content doesn't match the hash of
the file saved in disk.
For now plaster always produce a .patchfile when processing a plaster,
to avoid unnecessary writes and to confirm that submitted patches do
have the expected content. This may change in the future with a more
mature approach where the contents of the patchinfo file may be used
to avoid running all the plaster transformations. This means that for
now we have to pay for a full plaster generation to determine if a file
source/patch/patchinfo are out-of-date.
Resolves https://github.com/brave/brave-browser/issues/47066
This is the initial prototype for 🩹 Plaster. This work is based on a
recenlty worked out proposal:
https://docs.google.com/document/d/1aPf7cMB5Pc_ssKFC_I4-mLHr-7D4lTqsvItSXY-WzQM/
Run this tool with:
```
tools/cr/plaster.py
```
The tool at the moment is in a very early prototyping stage, and there
are many tickets opened for it, to get it into a mature state. The
intent is to manage to deliver this in gradual steps, while acquiring
experience alongside the way.
- Plaster files.
These are TOML files, even though they look pretty similar to ini files.
Each `[[substitution]]` entry represents an individual regex operation to be
applied to a file. The format for plasters is something like this
```toml
[[substitution]]
description = ''
re_pattern = ''
replace = ''
re_flags = ''
count = 0
```
A user can list as many of these entries as necessary for each regex
that one desires to apply to a given source.
Resolves https://github.com/brave/brave-browser/issues/45051
cdesouza-chromium