| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new 'Defaults' class to represent definitions defaults
The Python 'jsonschema' module is used to validate the contents of the
Defaults file. This module is already included in Baserock 'build' and
'devel' reference systems by way of the 'openstack-common' stratum.
This commit embeds a copy of the JSON-Schema schema for the DEFAULTS
file. I think the canonical location of this schema should be in the
reference definitions.git, for now. In future, the schemas should maybe
have their own repos. Either way, Morph should embed a copy for the time
being so that we are sure the schema matches how Morph expects to parse
the file.
Morph's automated tests are all updated to use definitions version 7.
I removed most of the tests for built-in build systems, because the
built-ins themselves are no longer part of Morph. Only the mechanism for
defining them needs to be tested now.
Change-Id: I65f8f1c967683ef605852bfae5c68518e53f9981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Loading .morph files is becoming a bit more complicated, as we need to
deal with the VERSION file, and possibly soon with a DEFAULTS file as
well.
The logic of loading and parsing .morph files is done either in the
sourceresolver module, or the morphloader module. This change means that
all users of the latter module can use the get hold of a
MorphologyLoader instance with VERSION already parsed. If DEFAULTS is
added then it is also simple to parse DEFAULTS.
Change-Id: Ib33756e9dbd078e38f12dd7f776c89584b178959
|
|
|
|
| |
Change-Id: I992dc0c1d40f563ade56a833162d409b02be90a0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to use file paths to locate morphologies now, so the old model
of get a list of names and hand it those back to get the contents
doesn't really make sense any more.
This abstraction initially came about as one idea I had for moving
morphologies out of the source tree was to put them in something like
git notes, where it's possible to look up information for one commit in
another ref in the repository, at which point this abstraction would
have been flexible enough to handle that as well as in the
However, moving the chunk morphologies into the definitions repository
has other benefits too, so it makes more sense to be honest about using
filenames in the API.
It remains as a single point where we can put the logic for knowing which
files in a repository look like morphologies, but if we need to remove
any further functionality, it should be replaced by a single function.
|
|
MorphologyFinder is a small wrapper on top of GitDirectory that
allows the inspection of morphologies in the repository.
Its purpose is to isolate the logic for reading morphologies into one
place.
It is used by passing a GitDirectory and optionally a ref to the
MorpholgyFinder constructor, then list_morphologies and read_morphology
may be used.
The ref is passed directly to the GitDirectory, so its semantics for
a ref of None or omitted are used. i.e. It uses the working tree.
Ref resolving is deferred until a morphology is listed or read, so
it will not raise an exception for an invalid ref until then.
|