Rename strictyaml to yamlcfg

[julie777]

Feel free to raise an issue for any of the following:

• Feature request

Because, from what I have read, strictyaml is not parseable by a yaml parser it isn't "yaml", instead it is yaml-like. Strict implies to many people that it is yaml with stricter rules, but that isn't the case.

I think the name strictyaml has the wrong connotation and doesn't say what it really is. This is shown by people complaining that it can't create Python objects (which isn't safe).

My reason for suggesting yamlcfg is based on use of yaml syntax, but without all of the object mapping and cycles, etc. That makes it safe for use as a configuration file. It can in fact be use for other purposes, but as a simple data file for config it:

• provides a very readable format
• is less noisy than other formats such as toml or json
• structure of the data is much more obvious than toml
• parsing can easily be type accurate, or relaxed
• allows comments
• doesn't require quoting all the strings

I do have one concern based on https://github.com/crdoconnor/strictyaml/blob/master/hitch/story/map.story which has some syntax that I don't understand.

• It is obvious that '-' is a list item
• I don't know what a '|' after the colon means

[julie777]

or better yamlconfig

[jnichols0]

Could you show an example of something strictyaml parses that isn't valid yaml? I don't think that's desirable, as my understanding is it's explicitly meant to be a strict subset of yaml.

The "|" denotes literal style, you can read about it here https://yaml.org/spec/1.2.2/#literal-style

[julie777]

Could you show an example of something strictyaml parses that isn't valid yaml? I don't think that's desirable, as my understanding is it's explicitly meant to be a strict subset of yaml.

I'm not sure about this one. I think I just read it somewhere. Please ignore.

The "|" denotes literal style, you can read about it here https://yaml.org/spec/1.2.2/#literal-style

Thanks. I figured it out when I started reading the full yaml doc.

(I don't think someone should have to read the full yaml doc to use strictyaml. To that end I have started writing a stripped down version of the parts of yaml that strictyaml supports.)

[julie777]

My initial suggestion was based on reading the documentation which both implies and outright states that strictyaml is used for config files because it is better than toml. (I certainly agree, because I hate all the repetition in toml, and the requirement to quote all strings.)

I also discovered your repo for Ultra Simple Yaml which seems more geared to config file use. But coming from the perspective of a pyproject.toml user, USY is too restricted for config file use.

And after working with strictyaml and pyyaml (since it has been a few years since I used yaml) I believe that strictyaml is too powerful/feature rich for config files.

I think that either USY should be extended to become yamlconfig, or a new yamlconfig should be started.

(This would be better as a discussion I think.)

Features of yamlconfig

1. leave all the comment support in
2. empty files are allowed
3. the document can only consist of a block of mappings, because an unnamed list as the contents of a config file doesn't make sense and neither does a single literal.
4. nesting is required, because many config files need it. Consider pyproject.yaml as the primary example for defining yamlconfig.

I haven't spent enough time thinking about this and mocking up examples to decide about some of the other features of strictyaml that could be removed. I do think it should be obvious to any programmer what a yamlconfig file means. This means that it is likely that some of the scalar variations should be removed. An example of this would be "|" literal style. Or possibly there is never a reason for quoting in yamlconfig, but again it needs more research.

[jnichols0]

I am not the creator/maintainer, just a power user and small time contributor, but I think I can help clarify some stuff.

StrictYAML can certainly be used for validating config files but it's definitely not just for that. It explicitly states that it's a strict subset of yaml, removing perceived problematic aspects. For instance, I use it in my project both for validating user created data and user created config files using a schema. Your "yamlconfig" idea could be implemented with a schema. With that, you load your config files disallowing stuff like a top level "unnamed" list, allowing empty files, among other things. Nested elements are certainly supported too.

Check out the "Quickstart with schema" section on this page to see an example of how to use a schema: https://hitchdev.com/strictyaml/

Hope this helps.

[julie777]

@jnichols0 Thanks.

I already retracted my suggestion for renaming strictyaml because it sits in a great place, which I believe is better that yaml safe_load.

I understand that I can control what is allowed by validating.

My thoughts were more about having a version that is somewhere between strictyaml and ultra simple yaml that provides what is necessary for config files, and only that. The benefit here is that a document specifying what is allowed would be very short and make it much simpler to use.

Just my opinion, but I much prefer documentation that shows me what I can do, to documentation that says "read this other monster document and just ignore the following parts..."

I have been creating and running test documents through strictyaml and working to reduce https://yaml.org/refcard.html to only what strict yaml supports. My goal is to have the refcard and a single page of examples provide enough information for someone to use strictyaml correctly (not including validation).