Cache-related issue with pyside6

[ZeeD]

Describe the bug

Honestly I'm not sure if the real culprit here is in how the cache is implemented or how pyside6 works but...

If I have install.cache = True and, in my project, I add PySide6 as dependency, I cannot run the executables contained in the packages - for example pyside6-designer.

I think the issue here is that PySide6 depends on PySide6-Addons and PySide6-Essentials and that all of them share the same "root package" PySide6 - each of them with the __init__.py file

$ ls ~/.cache/pdm/packages/pyside6*-6.10.0-cp39-abi3-manylinux_2_34_x86_64.whl.cache/PySide6/__init__.py
~/.cache/pdm/packages/pyside6-6.10.0-cp39-abi3-manylinux_2_34_x86_64.whl.cache/PySide6/__init__.py
~/.cache/pdm/packages/pyside6_addons-6.10.0-cp39-abi3-manylinux_2_34_x86_64.whl.cache/PySide6/__init__.py
~/.cache/pdm/packages/pyside6_essentials-6.10.0-cp39-abi3-manylinux_2_34_x86_64.whl.cache/PySide6/__init__.py

FYI the pyside6-designer tool is in PySide6-Essentials

 ls ~/.cache/pdm/packages/pyside6*-6.10.0-cp39-abi3-manylinux_2_34_x86_64.whl.cache/PySide6/designer 
~/.cache/pdm/packages/pyside6_essentials-6.10.0-cp39-abi3-manylinux_2_34_x86_64.whl.cache/PySide6/designer

but in my project venv there is a symbolic link from PySide6/__init__.py from just one of them, specifically to the one offered by PySide6Addons

$ ls .venv/lib/python3.13/site-packages/PySide6/__init__.py 
.venv/lib/python3.13/site-packages/PySide6/__init__.py -> ~/.cache/pdm/packages/pyside6_addons-6.10.0-cp39-abi3-manylinux_2_34_x86_64.whl.cache/PySide6/__init__.py

this means that the "other two" __init__.py are lost.
I think this might be just a case of "override", where just the last package installed "wins", but I haven't really tried.

One of the effect is that the pyside machinery used internally broke and tries to call the designer binary in the "wrong" package

'~/.cache/pdm/packages/pyside6_addons-6.10.0-cp39-abi3-manylinux_2_34_x86_64.whl.cache/PySide6/designer'

apart from this error, I was wondering if there was something from pdm install that may alert the user about this scenario - or if there was another way to support this scenario

To reproduce

• set config
• create a project adding pyside6 as dependency
• try to execute pyside6-designer

Expected Behavior

pyside6-designer starts

Environment Information

$ pdm info && pdm info --env
PDM version:
  2.26.0
Python Interpreter:
  ~/eclipse-workspace/pqtdiff3/.venv/bin/python (3.13)
Project Root:
  ~/eclipse-workspace/pqtdiff3
Local Packages:
  ~/eclipse-workspace/pqtdiff3/.venv/lib/python3.13/site-packages
{
  "implementation_name": "cpython",
  "implementation_version": "3.12.9",
  "os_name": "posix",
  "platform_machine": "x86_64",
  "platform_release": "6.16.9+deb14-amd64",
  "platform_system": "Linux",
  "platform_version": "#1 SMP PREEMPT_DYNAMIC Debian 6.16.9-1 (2025-09-27)",
  "python_full_version": "3.13.7",
  "platform_python_implementation": "CPython",
  "python_version": "3.13",
  "sys_platform": "linux"
}

Verbose Command Output

No response

Additional Context

No response

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.

[frostming]

One of the effect is that the pyside machinery used internally broke and tries to call the designer binary in the "wrong" package

That is an embarrassed situation, when not using cache, it last __init__.py wins as well but all packages are installed side by side the machinery can find the binary correctly. What is wrong is that the machinery should not resolve the symlinks when calculating file locations.

I don't think that is something PDM can solve. But I'm not quite clear why you need to rely on automatic lookup to call the designer.

[ZeeD]

the only action that might be taken by pdm I think is that that it might alert the user in case multiple packages tries to "offer" (with the consequence of the override) the same package/module - I'm at work now but I'm not sure the three PySide6/__init__.py files where just empty.

I had a very brief look at the pyside internals and I'm not sure about why there was even the need to resolve the symlink in the first place, but I agree with you that it's an issue on their side - what I can do is open a ticket there and ask the team if they can fix this on their side.