ryan95f/yamlator

Yamlator is a CLI tool that allows a YAML file to be validated using a lightweight schema that defines the expected structure. When executed, the YAML is compared against the rules to validate that the relevant keys and data types are present. Once validated, a list of violations will be displayed to help amend the YAML file.

yamlator's Issues

Strict ruleset validation

First off, this is a super cool module. Very well documented and designed. I would like to see an option, however, to run strict validation of a ruleset, such that I could create a ruleset that would only allow a listed set of keys. As I understand it currently from the documentation, this doesn't seem to be possible.

Say that I have a data structure that looks like this:

foo:
  bar: true
  baz: false
  qux: 11

I would expect that I could validate this structure with something like

ruleset Foo {
    bar bool required
    baz bool required
    qux int required
}

schema foo {
    foo Foo
}

And while that will validate successfully, if I was to add quux: corge into foo, then it would still validate successfully, even though quux is not a listed valid key name.

Dash in a rule name results in a parsing error

Just discovered a fun little bug. Looks like dashes in rule names will generate a syntax error. Something like this:

Error on line 118, column 8.

    foo-bar Baz optional
       ^

You can use the following to replicate it:

ruleset Baz {
    qux str optional
}

schema {
    foo-bar Baz optional
}

Python 3.6 support

Welp, things had been going great and I was just about ready to start trying to get some code utilizing yamlator into production when I made a terrible realization... we use centos 7 in production and all that's available is Python 3.6. Is there anything that yamlator explicitly needs in Python 3.7? Or is there a chance we can drop the version requirement down one version to 3.6+?

Schema/ruleset inheritance

Probably one of the biggest things I'm finding as I'm writing that makes my rulesets more complicated than necessary is that I find myself repeating myself a lot when the models I'm attempting to mock inherit from a parent class and have additional attributes or even override the parent. This ends up resulting in a vastly verbose instruction set that either has a lot of mostly duplicated rulesets, or a single ruleset that is not as strict as it could be, due to needing to encompass coverage for all of its child classes.

So, probably the best way to handle this would be pull over a concept of class inheritance so that rulesets could more closely mirror classes that they're intended to model

As an example, here's one possible implementation:

strict ruleset Component {
  enable bool
  resources map(str)
  dependencies map(Services)
}

strict ruleset Apache(Component) {
  listening_port int
  ssl bool
}

In this example, it's assumed that the Apache component inherits all the attributes of its parent ruleset before expanding the available attributes.

I wouldn't call this a huge priority to implement, especially since things work the way they are right now, just with a bit more verbosity than may be desired.

Validate schemas with a top level list

At the moment, it's not really possible to validate a schema where the top level datastructure is a list. This is pretty common in a lot of places and probably is something for future enhancement. You might have a datastructure like so:

- foo:
   bar: true
   baz: false
- qux:
  bar: false
  baz: true

And it would be nice to be able to validate it with something like a special rule key called something like !!rootlist and be able to define a data structure like so:

strict ruleset Foobar {
    bar bool
    baz bool
}

schema {
    !!rootlist Foobar
}

Alternatively, it could just be a different kind of schema, something like this:

listschema {
    Foobar
}

Broaden character support for quoted rule names

As mentioned in #44 where it was discovered that rule keys didn't support dashes, it has become apparent that rule keys don't currently support the full character set of available string values that can be used in YAML. Notably, they do not currently support spaces, which are fairly commonly used in string keys in YAML due to its natural language-like syntax. In order to add this support, we'll need to change the syntax to allow for quoted strings to be passed as rule keys, which will likely create both a plain bareword string syntax, as well as a quoted string syntax. As it stands, I would expect that we could leave the existing regex in place to match bareword strings, though, quoted strings should probably provide support for spaces. This could probably take advantage of the built-in common.ESCAPED_STRING rule (though I personally couldn't figure out how to get it to work).

I'd think that bareword strings should probably be based on the previous regex as well, something like /[a-zA-z0-9_-]+/. Though, I'd say that's probably not as big of a deal

Support for union data types

First off, thanks again for quickly adopting my previous suggestion. Here's to hoping this is an even easier one. It would be handy if there could be a union type that allows multiple types to be tested. I have a few instances where either a string or an integer would be acceptable. But, this could be powerful in that it could allow for the simplification of regexes by allowing multiple simple regexes to be supplied for complex validations rather than trying to build one big scary one that can encompass all potential cases.

I was thinking that a potential implementation would look something like union(<type1>, <type2>, ...) so that you could have N number of types you test. Short of maybe allowing imports from another file, I can't think of too many other things that this schema grammar really needs.