You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using this structure allows me to have some application that brings it's own lib-b, that satisfies the ^x.y.z version requirement, but is not x.y, as given in the dev dependencies.
app's pyproject.toml
[tool.poetry]
name = "app-a"
[tool.poetry.dependencies]
lib-a = { "git": "...", branch = "b.c" }
lib-b = { "git": "...", branch = "x.a" } # where x.a's provided version satisfies ^x.y.z
Ok. So far so good. But when I now try to list the outdated dependencies on lib-a, it can't find a direct dependency type for lib-b, and raises a RuntimeError with message "Unknown direct dependency type None"
full shell output
$ poetry show --outdated -vvv
Loading configuration file /home/username/.config/pypoetry/config.toml
Using virtualenv: /home/username/path/to/.venv
Project environment contains an empty path in sys_path, ignoring.
[keyring.backend] Loading KWallet
[keyring.backend] Loading SecretService
[keyring.backend] Loading Windows
[keyring.backend] Loading chainer
[keyring.backend] Loading libsecret
[keyring.backend] Loading macOS
Creating new session for pypi.org
Source (PyPI): 1 packages found for<package-name>
Stack trace:
9 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/cleo/application.py:329 in run
327│
328│ try:
→ 329│ exit_code = self._run(io)
330│ except Exception as e:
331│ if not self._catch_exceptions:
8 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/poetry/console/application.py:185 in _run
183│ self._load_plugins(io)
184│
→ 185│ exit_code: int = super()._run(io)
186│ return exit_code
187│
7 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/cleo/application.py:423 in _run
421│ io.input.set_stream(stream)
422│
→ 423│ exit_code = self._run_command(command, io)
424│ self._running_command = None
425│
6 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/cleo/application.py:465 in _run_command
463│
464│ if error is not None:
→ 465│ raise error
466│
467│ return event.exit_code
5 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/cleo/application.py:449 in _run_command
447│
448│ ifevent.command_should_run():
→ 449│ exit_code = command.run(io)
450│ else:
451│ exit_code = ConsoleCommandEvent.RETURN_CODE_DISABLED
4 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/cleo/commands/base_command.py:119 in run
117│ io.input.validate()
118│
→ 119│ status_code = self.execute(io)
120│
121│ if status_code is None:
3 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/cleo/commands/command.py:83 in execute
81│
82│ try:
→ 83│ returnself.handle()
84│ except KeyboardInterrupt:
85│ return 1
2 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/poetry/console/commands/show.py:235 in handle
233│
234│ if show_latest:
→ 235│ latest = self.find_latest_package(locked, root)
236│ if not latest:
237│ latest = locked
1 ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/poetry/console/commands/show.py:511 in find_latest_package
509│ if dep.name == package.name:
510│ provider = Provider(root, self.poetry.pool, NullIO())
→ 511│ return provider.search_for_direct_origin_dependency(dep)
512│
513│ name = package.name
RuntimeError
Unknown direct dependency type None
at ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/poetry/puzzle/provider.py:244 in search_for_direct_origin_dependency
240│ dependency = cast("URLDependency", dependency)
241│ package = self._search_for_url(dependency)
242│
243│ else:
→ 244│ raise RuntimeError(
245│ f"Unknown direct dependency type {dependency.source_type}"
246│ )
247│
248│ ifdependency.is_vcs():
To resolve this, the script could have known that the dependency is always fetched from the vcs location given elsewhere, but it does not resolve this. Going this path is a bit complicated.
Another possible easy solution would be to catch the error and ignore it entirely (what's outdated in the context of something that does not seem to exist at all?). Currently that requires catching a rather unspecific RuntimeError exception. Going this patch is easier, when a more specific exception class is used.
What do you think? Is there a better way to do this in the first place? Are one of the above good possible solutions?
The text was updated successfully, but these errors were encountered:
I've got some private library (say, lib-a), that depends on some other private library (say, lib-b). I'm lazy, distributing private libs using git.
Using this structure allows me to have some application that brings it's own lib-b, that satisfies the ^x.y.z version requirement, but is not x.y, as given in the dev dependencies.
app's pyproject.toml
Ok. So far so good. But when I now try to list the outdated dependencies on lib-a, it can't find a direct dependency type for lib-b, and raises a RuntimeError with message "Unknown direct dependency type None"
full shell output
What do you think? Is there a better way to do this in the first place? Are one of the above good possible solutions?
The text was updated successfully, but these errors were encountered: