Adding the programming language tag to TESTed#583
Conversation
jorg-vr
left a comment
jorg-vr
left a comment
There was a problem hiding this comment.
Please add tests:
- old format still works but adds a deprecation warning
- new format works
- the deprecation warning is only added once
| "--translate", | ||
| type=str, | ||
| help="Specifies the language to translate translate the dsl to.", | ||
| default="-", |
There was a problem hiding this comment.
This is actualy a change that already should be in the other branch. This default will cause the translator to run when the option -t isn't even provided.
| messages.append( | ||
| ExtendedMessage( | ||
| f"WARNING: You are using YAML syntax to specify statements or expressions in multiple programming languages without the `!programming_language` tag. This usage is deprecated!", | ||
| permission=Permission.STAFF, |
There was a problem hiding this comment.
@bmesuere, this gave me the idea that we might need to add a Permission.CREATOR or something like that in the future. Some messages just aren't very actionable for teachers using exercises that are not their own.
We might also want to mark exercises with unresolved warnings/errors in dodona and create a page to review these for content creators
| ] | ||
|
|
||
|
|
||
| def build_translate_parser_messages( |
There was a problem hiding this comment.
I wouldn't take a boolean argument here, nor would I return a list, as it is a single message
And rename it to build_deprecated_language_message or something like that
There was a problem hiding this comment.
I wrote it like this such that this function can easily be expanded when extra deprecation warnings pop-up about using file instead output_files.
| # TODO: In the PR of adding file usage to the DSL, other deprecation warnings were added during parsing. | ||
| # So I think it's a nice split to have messages from parser and from the preprocessor. | ||
| collector.add_messages( | ||
| build_translate_parser_messages(bundle.suite.using_deprecated_prog_languages) |
There was a problem hiding this comment.
Same as in the natural_languages pr, this method won't be needed here if we had bundle.parser_messages
There was a problem hiding this comment.
I've resolved all the other notes because it boils down to this. I changed the usage of booleans to an actual list of ExtendedMessages
jorg-vr
left a comment
jorg-vr
left a comment
There was a problem hiding this comment.
Looks good, left some mostly minor nitpicks
3 participants
This builds of the PR #574. The goal is to add the tag
!programming_languagesuch that it is more consistent with the usage of the tag!natural_language.