Created
September 14, 2017 19:22
-
-
Save perlpunk/9f2004eebee4486b8cf08f4fdc18a963 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 2017-09-09 20:51:17 < tinita> flyx, ingy when I added tests with tags, i often used !foo or !a, !b | |
| 2017-09-09 20:51:31 < tinita> when loading, frameworks complain about those | |
| 2017-09-09 20:51:51 < tinita> so i think i should convert those to !!str, etc. where appropriate | |
| 2017-09-09 20:52:02 < tinita> so that we can better test loading | |
| 2017-09-09 20:52:22 < flyx> if the framework is not low-level enough, the problem is probably that it tries to resolve the t | |
| ag to a type and finds none that is registered | |
| 2017-09-09 20:52:51 < flyx> perhaps we can first evaluate whether the test adapter for the framework uses the apropriate API | |
| ? | |
| 2017-09-09 20:53:21 < flyx> I would be confused if a framework rejects !a when only an event stream is queried | |
| 2017-09-09 20:53:28 < tinita> for example, pyyaml or ruamel can parse it, but the loader complains | |
| 2017-09-09 20:54:12 < tinita> pyyaml says: | |
| 2017-09-09 20:54:20 < tinita> yaml.constructor.ConstructorError: could not determine a constructor for the tag '!local' | |
| 2017-09-09 20:54:41 < flyx> I think, if we want to test the complete loading process, we would need a different set of test | |
| cases. | |
| 2017-09-09 20:55:04 < flyx> the current tests are for the parser and we should grab the output at that level. does the pyyaml test adapter not do that? | |
| 2017-09-09 20:55:07 < tinita> yeah,or at least make the existing tests loadable | |
| 2017-09-09 20:55:36 < tinita> i am using the tests for parsing, constructing, dumping and emitting | |
| 2017-09-09 20:55:55 < tinita> in the yaml-editor there is pyyaml.event and pyyaml.py | |
| 2017-09-09 20:56:01 < tinita> the latter one complains | |
| 2017-09-09 20:56:27 < flyx> hmm. not sure if that is a good idea. pyyaml *does* support !local, if configured properly. we should be able to test whether it passes through the parser | |
| 2017-09-09 20:56:42 < tinita> i think it doesn't hurt to just use the standard tags, though | |
| 2017-09-09 20:56:54 < flyx> perhaps we could tag tests that should be loadable without configuration? | |
| 2017-09-09 20:56:57 < tinita> in many cases the test is just about general tag syntax | |
| 2017-09-09 20:57:21 < tinita> i think we need a general change for the test suite anyway | |
| 2017-09-09 20:57:33 < tinita> the test should contain something like this: | |
| 2017-09-09 20:57:35 < flyx> well, we can certainly reduce the occurrence of local tags where the tests are not about them. | |
| 2017-09-09 20:58:00 < flyx> as long as we keep some local tags, I'm okay with that | |
| 2017-09-09 20:58:16 < tinita> { 1.2: { parse: ok, construct: error }, 1.3: { ... } } | |
| 2017-09-09 20:58:54 < tinita> i think the test tags are not sufficient for that | |
| 2017-09-09 20:59:01 < flyx> maybe | |
| 2017-09-09 20:59:53 < tinita> ok, i'll look for local tags and create a PR | |
| 2017-09-09 21:00:40 < tinita> so maybe: | |
| 2017-09-09 21:00:43 < tinita> +++ result | |
| 2017-09-09 21:00:52 < flyx> I wonder whether we want to encode the metadata of the tests with YAML ;) | |
| 2017-09-09 21:01:04 < tinita> { "1.2": ... } # json | |
| 2017-09-09 21:01:14 < flyx> yeah, json would be better, I think | |
| 2017-09-09 21:01:18 < tinita> yeah =) | |
| 2017-09-09 21:01:47 < tinita> especially for people who write a yaml parser in a language which doesn't have a yaml paser already ;-) | |
| 2017-09-09 21:05:29 < tinita> and the json can include line and column number in case of an error | |
| 2017-09-09 21:06:21 < tinita> so that we can test if the error occurred at the expected location | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment