-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add collection version to plugin pages and collection plugin index #200
Merged
abadger
merged 14 commits into
ansible-community:main
from
felixfontein:collection-version
Nov 30, 2020
Merged
Changes from 11 commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
105b314
Add collection versions.
felixfontein 0307b28
Linting.
felixfontein 28d4130
Also retrieve collection paths.
felixfontein b60e840
Address review comments.
felixfontein ef068c6
collection_info -> collection_to_plugin_info
felixfontein e041575
collection_infos -> collection_metadata
felixfontein 8521bdc
Remove optionals.
felixfontein 1f2dc20
Fix mistake.
felixfontein 0996b65
Convert AnsibleCollectionDocs into a NamedTuple.
felixfontein 3a29a34
Add collection name as title. Fixes #219.
felixfontein 892998d
Replace NamedTuple with plain tuple.
felixfontein 9f0a1ca
Crash if collection has no metadata.
felixfontein 54ed7ce
Use concrete type.
felixfontein 298eafb
Linting.
felixfontein File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason not to do this would be that the types for return values should be concrete: We know we're returning a DefaultDict of Dicts because we're creating those inside of this function. So anything making use of our return values would know they can depend on those behaviours being present. Typing it as generic Mapping of Mapping means that code using our return value can't depend on those behaviours.
Input types, otoh, should specify the least common denominator that they need. So in terms of taking input, a Mapping is appropriate unless the function wanted to do something that depended on the DefaultDict's behaviour.
I kind of feel like we should keep return types and input types separate for that reason (when they're different). Does it make sense to define a return spec alongside the input spec so that it's easier to write this sort of thing and see that they're compatible types? (like
RetCollectionInfoT
as a counterpart toCollectionInfoT
?) Or does that defeat the purpose of keeping the input type as lowest common denominator?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually things like "this implementation uses a
defaultdict
" is an implementation detail and callers should not depend on that, because it makes it really hard to change the implementation without having to go through all callers to make sure they don't depend on it. (If a generic Mapping is documented, they can of course still use it like adefaultdict
, but then they're clearly faulty.)Using
CollectionInfoT
here says to API users that "this collection returns what can be used in other APIs asCollectionInfoT
", as opposed to "we return this concrete mapping type, which might be similar to one of the input types of other functions, but you have to figure that out by yourself". Also, definingRetCollectionInfoT
different fromCollectionInfoT
makes it impossible to ever provide any function returning that which does not use a similar implementation (based ondefaultdict
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed in 54ed7ce.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting..... So I don't think of static typing info as part of the API but I can definitely see your point that if it is, then we should be using it to define capabilities to expect rather than the specific type. I guess there's two separate use cases (static typing to catch errors in the current implementation vs static typing to define the expected API) and in this specific case they're a little bit at odds.
There are cases where defaultdict and dict behaviour would be different even though you are only using functions that are common to both, so I think it can be beneficial to know concretely what we're returning. To be fair, I don't think static typing will prevent it (at this stage in type checkers' development, at least), though so type checking might not be the place to specify this and enforce it.... An example would be the following code: