[pip 22.1] 'PathDistribution' object has no attribute 'project_name'

[imba-tjd]

> pipdeptree.exe
Ignoring invalid distribution ~iztracer (C:\Users\imbat\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages)
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "c:\users\imbat\appdata\local\packages\pythonsoftwarefoundation.python.3.11_qbz5n2kfra8p0\localcache\local-packages\python311\scripts\pipdeptree.exe\__main__.py", line 7, in <module>
  File "C:\Users\imbat\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\pipdeptree.py", line 878, in main
    tree = PackageDAG.from_pkgs(pkgs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\imbat\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\pipdeptree.py", line 290, in from_pkgs
    pkgs = [DistPackage(p) for p in pkgs]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\imbat\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\pipdeptree.py", line 290, in <listcomp>
    pkgs = [DistPackage(p) for p in pkgs]
            ^^^^^^^^^^^^^^
  File "C:\Users\imbat\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\pipdeptree.py", line 149, in __init__
    super(DistPackage, self).__init__(obj)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\imbat\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\pipdeptree.py", line 109, in __init__
    self.project_name = obj.project_name
                        ^^^^^^^^^^^^^^^^
AttributeError: 'PathDistribution' object has no attribute 'project_name'

[imba-tjd]

I have figured it out. It's a pip issue. The change was made in pypa/pip#11044, between 22.1b and 22.1

For now. If anyone wants to use pipdeptree, set _PIP_USE_IMPORTLIB_METADATA=0

[ssbarnea]

Yep, same problem on 3.11. Sadly it does not seem to be well maintained.

[naiquevin]

Thanks. Unfortunately I have been caught up with other things and don't have time to work on pipdeptree in the immediate future. I'll try to find time by the end of this month.

Good that _PIP_USE_IMPORTLIB_METADATA=0 can be used as a work around in the meanwhile.

[stonebig]

trying to patch uglily first two errors line 109 & 110 :

    def __init__(self, obj):
        self._obj = obj
        self.project_name = obj.name #  obj.project_name
        self.key = obj.name.replace('-', '_').lower() # obj.key

I fall on line 293, and can't find out this one

pipdeptree -r -p wheel
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "D:\python-3.11.0b5.amd64\Scripts\pipdeptree.exe\__main__.py", line 7, in <module>
  File "D:\python-3.11.0b5.amd64\Lib\site-packages\pipdeptree.py", line 878, in main
    tree = PackageDAG.from_pkgs(pkgs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\python-3.11.0b5.amd64\Lib\site-packages\pipdeptree.py", line 292, in from_pkgs
    m = {p: [ReqPackage(r, idx.get(r.key))
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\python-3.11.0b5.amd64\Lib\site-packages\pipdeptree.py", line 293, in <dictcomp>
    for r in p.requires()]
             ^^^^^^^^^^^^
TypeError: 'NoneType' object is not callable

[ssbarnea]

@naiquevin it is perfectly ok to be busy, but if you really care about pipdeptree, just move it under an org and give others access to fix and maintain it.

[naiquevin]

@ssbarnea I have opened an issue in the pip repo to check if they would be interested in adopting pipdeptree by moving the code inside pip itself. IMO that would be better in the long run rather than maintaining the project externally. - pypa/pip#11360

However, I can see that there's a huge backlog of issues on pip, so expect this to take time. If they are not interested, I'll move it under an org as you suggested.

In the meanwhile I am assuming that any one can fork the project, merge open PRs on any of the public forks, and install pipdeptree into their env from their own fork on github or any other origin for that matter. I am curious about what stops people from doing this? Isn't that the whole point of git?

I don't mean any offense here, please don't get me wrong. As the owner of the pipdeptree on github and pypi.org, I know that it's my responsibility to care about it and ensure timely releases. But due to pipdeptree's dependence on pip's internals, a "stable" version can suddenly become unstable when a new version of pip is released. It's usually not possible for me to drop whatever I am doing and fix it. If there are any PRs I believe I have a greater responsibility to avoid any regression by doing end-to-end test myself before merging them. So it could take some time for PRs to get merged.

Again, no offense meant. But recently I've noticed comments on my projects that imply it's my responsibility to not just maintain the project, but also unblock them on high priority. Not saying you meant that too but I did feel a mild nudge given my recent experience on github in general (not just this project).

[ssbarnea]

pypa org will not accept projects without active maintainers, as they do not want to become a junkyard. You can still move it to pycontribs or if you want, keeping the ownership.

I am one of the maintainers or pip-tools and we are still not moved to pypa, but looking to in the future.

As pip recently got the inspect feature, i was wondering if it would not be better to reimplement pipdeptree inside pip-tools, especially as we already have two tools in it.

Yep, keeping up with packaging changes is a challenge.

[stonebig]

@ssbarnea maybe you can propose a patch ? pip may be more inclined to integrate pipdeptree if the current issue is fixed.

[ssbarnea]

I think that pip team is very careful to minimize the amount of baggage the tool adopts, so unlikely to implement it. We should at least ask, maybe I am wrong.

[stonebig]

When trying to build an updated set of packages, I'm truly lost without pipdeptree to navigate dependancies.

[stonebig]

the suggested solution "pip pinspect" per pipa team sounds like a good splitting of duties

[naiquevin]

@ssbarnea Looks like the pip team is reluctant about the proposal, as you had predicted.

As pip recently got the inspect feature, i was wondering if it would not be better to reimplement pipdeptree inside pip-tools, especially as we already have two tools in it.

I was not aware of pip inspect. If the json interface is indeed stable, I don't see why it can't be used to build a tool like pipdeptree.

Please feel free to reimplement it in pip-tools. Let me know once your version reaches stable state, I would happily archive this project and link it to yours.