On 10/04/2018 14:34, Ted Mielczarek wrote:
On Tue, Apr 10, 2018, at 9:23 AM, James Graham wrote:
On 10/04/2018 05:25, glob wrote:
mozilla-central contains code vendored from external sources. Currently
there is no standard way to document and update this code. In order to
facilitate automation around auditing, vendoring, and linting we intend
to require all vendored code to be annotated with an in-tree YAML file,
and for the vendoring process to be standardised and automated.
The plan is to create a YAML file for each library containing metadata
such as the homepage url, vendored version, bugzilla component, etc. See
https://goo.gl/QZyz4xfor the full specification.
So we now have moz.build that in addition to build instructions,
contains metadata for mozilla-authored code (e.g. bugzilla components)
and moz.yaml that will contain similar metadata but only for
non-mozilla-authored code, as well as Cargo.toml that will contain (some
of) that metadata but only for code written in Rust.
As someone who ended up having to write code to update moz.build files
programatically, the situation where we have similar metadata spread
over three different kinds of files, one of them Turing complete,
doesn't make me happy. Rust may be unsolvable, but it would be good if
we didn't have two mozilla-specific formats for specifying metadata
about source files. It would be especially good if updating this
metadata didn't require pattern matching a Python AST.
We are in fact rethinking the decision to put file metadata in moz.build files
for these very reasons. I floated the idea of having it live in these same YAML
files that glob is proposing for vendoring info since it feels very similar. I
don't want to block his initial work on tangentially-related concerns, but I
think we should definitely look into this once he gets a first version of his
vendoring proposal working. I don't know if there's anything useful we can do
about Cargo.toml--we obviously want to continue using existing Rust practices
there. If there are specific things you need to do that are hard because of
that I'd be interested to hear about them to see if there's anything we can
improve.
That's great to hear! The main thing I currently have to do is
automatically update bug component metadata when files move around
during wpt imports. However one can certainly imagine having to script
similar metadata updates For example, I assume that wpt is not "third
party" code according to the terms of this discussion, since it's also
edited in-tree, and whatever tooling we have to support generic third
party repos won't apply. But it would make sense to store the upstream
revision of wpt in there rather than in one-off custom file like we do
currently. So reusing the same moz.yaml format everywhere rather than
having one case for "local" code and one for "remote" would make sense
to me as someone maintaining what amounts to an edge case.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
