reintroduce deprecated support for old-style container args #340
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
alternative to #338, we should only pick one.
The old, undocumented (I think?) way of specifying containers on the command-line continues to work with a deprecation message.
The way I've implemented deprecations here prevents new-style args that pass the 'looks like a literal' test. That means there would be no way to properly specify the list
["[1]"]
on the command-line. I'm not too concerned about it, but it's a theoretical issue. The alternative to that is to keep the logic here for warnings, but don't try to support the old-style args. That way you can specify anything in the new-style, and users will get a pointer if they use the old-style, but attempts to use the old-style will generally result in errors.I have a slight inclination toward deprecate-and-keep-working over break-with-informative-message, but if someone can point to a more serious problem that the deprecation will break, I'm happy to change.
closes #338