-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Pyreverse: Use dashed lines for type-checking imports #8824
Pyreverse: Use dashed lines for type-checking imports #8824
Conversation
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.
Those "empty arrows" have a meaning in UML it means generalization, i.e. "inherit from". The proper UML convention needs to be used, possibly dotted line with the same arrow for "dependency" see (14) here : https://stackoverflow.com/a/2293763/2519059.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #8824 +/- ##
=======================================
Coverage 95.89% 95.90%
=======================================
Files 173 173
Lines 18511 18523 +12
=======================================
+ Hits 17752 17765 +13
+ Misses 759 758 -1
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@DudeNr33 Something is off with the tests, but I can't what it is. There's some kind of interference with |
We currently do not have a equivalent to the functional test of class diagrams for package diagrams. @pytest.fixture()
def setup_type_check_imports_dot(
type_check_imports_dot_config: PyreverseConfig, get_project: GetProjectCallable
) -> Iterator[None]:
writer = DiagramWriter(type_check_imports_dot_config)
project = get_project(TEST_DATA_DIR, name="type_check_imports")
yield from _setup(project, type_check_imports_dot_config, writer) The first argument to The cleanest solution would probably be to come up with a working functional test harness for package diagrams as well. |
for more information, see https://pre-commit.ci
This comment has been minimized.
This comment has been minimized.
pylint/pyreverse/diagrams.py
Outdated
except KeyError: | ||
continue |
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.
These two lines are uncovered, and I don't know how to cover them. Any ideas? They could also be cut, or just ignore the coverage.
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 check is definitely required. But I can't figure out exactly what triggers it.
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.
I think this look dope, great change (especially in conjunction with the other option) ! Although I would appreciate a second / third opinion regarding the UML symbolic before we commit to it.
This comment has been minimized.
This comment has been minimized.
I am not an UML expert myself, but the link you provided sounds pretty reasonable to me! |
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.
Thank you Nick for the new feature. I like it.
I left some remarks.
I also think we should try to introduce real functional package diagram tests rather sooner than later after this PR. The functional tests for class diagram work more or less the same as the functional tests for messages - that is, you only need to create the input, output, and optionally config file and they will be picked up automatically in the test run.
This is not yet the case for the files below functional/package_diagram
, but the naming convention could make you believe it is.
This comment has been minimized.
This comment has been minimized.
codecov seems to be stuck. @Pierre-Sassoulas what's the best fix for this? Close/reopen the PR? |
Yeah, let's try ! |
There's some trickery with astroid's version but I'm not sure why readthedoc alone fail. Maybe bad caching. I'm half inclined to "just merge it ™️". |
Waiting for #7767 and a rebase might be best. |
🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉 This comment was generated for commit abcfcc2 |
Yeah, I didn't bother to pin the astroid commit in the docs/requirements.txt, so it was pulling from astroid 3.0.0a7. Should be good now 👍 |
} | ||
mod_b --> mod_a | ||
mod_d --> mod_a | ||
mod_c -.-> mod_a |
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.
This is not valid mermaid.
it should be:
mod_c ..> mod_a
as documented here:
https://mermaid.js.org/syntax/classDiagram.html#defining-relationship
github renders mermaid files, and if we try to open this one we get an error, see:
https://github.com/pylint-dev/pylint/blob/ffe1e714a3cfe83b5a627ade6d723489f2e10621/tests/pyreverse/functional/package_diagrams/type_check_imports/packages.mmd
@@ -24,6 +24,7 @@ class MermaidJSPrinter(Printer): | |||
EdgeType.ASSOCIATION: "--*", | |||
EdgeType.AGGREGATION: "--o", | |||
EdgeType.USES: "-->", | |||
EdgeType.TYPE_DEPENDENCY: "-.->", |
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.
this is the actual wrong line
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.
Thanks! Would you be willing to provide a PR?
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.
yep... just did!
#9031
Type of Changes
Description
This PR modifies the Pyreverse package diagram generator so that if module A only imports from module B under the
TYPE_CHECKING
flag, an empty arrow is used.Closes #8112
Here is an example of the output:
In this diagram, the
instrs
module is only imported for type checking, thetape
module is sometimes imported for type checking and sometimes imported for real, and the rest of the modules are all imported for real.There is an interesting interaction with the (still unreleased)
--no-standalone
option. Namely, a module only imported for type checking appears as a ghost module:I hadn't considered this in my implementation, but I think it actually works out pretty well.
TODO