mypy: adapt type hints to change in poetry-core#442#6163
Conversation
| # keep record of packages seen during recursion in order to avoid recursion error | ||
| seen_package_names = set() | ||
|
|
||
| def _extra_packages(package_names: Iterable[str]) -> Iterator[str]: |
There was a problem hiding this comment.
def _extra_packages(
package_names: Iterable[NormalizedName],
) -> Iterator[NormalizedName]:
and remove the redundant canonicalize_name() at line 52
| def get_extra_package_names( | ||
| packages: Sequence[Package], | ||
| extras: Mapping[str, list[str]], | ||
| extras: Mapping[str, list[NormalizedName]], |
There was a problem hiding this comment.
If we believe this change, then the call to canonicalize_name a few lines later is redundant and should be removed
I'm not completely sure that I do believe it: some callers populate this parameter by reading from the locker: is lock_data.get("extras", {}) definitely returning NormalizedNames?
I think the answer is that it is if the lockfile was written by a sufficiently recent poetry, possibly it isn't otherwise. This isn't normalized, even in recent poetry lockfiles: so this type annotation is faulty.
(I experimented with adding an extra like this
[tool.poetry.dependencies]
"zope.interface" = { version = ">=1", optional = true }
[tool.poetry.extras]
foo = ["zope.interface"]and the unnormalized zope.interface is carried through to the lockfile)
There was a problem hiding this comment.
Actually, poetry 1.2 should be able to read lock files generated by poetry 1.1. Thus, I think we should keep it.
There was a problem hiding this comment.
both poetry 1.1 and 1.2 write un-normalized strings to the lockfile and so the annotation is flat wrong.
ef9a76a to
e7d562e
Compare
e7d562e to
176f89a
Compare
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Necessary changes when updating poetry-core to a version containing python-poetry/poetry-core#442