poetry: poetry 1.2.0a1: AttributeError when installing package from secondary repo

This regression appeared in Poetry 1.1.7/1.1.9 two days ago when poetry-core 1.0.5 was released. Downgrading to poetry-core 1.0.4 is a workaround.

I had the same issue, with poetry 1.1.11, I downgraded poetry to 1.0.6 and it worked, but that was not the permanent solution as 1.1.11 brought new features, which were really handy in building/publishing wheels. After some research I found that poetry’s local cache was getting corrupted, since I built the packages multiple times. So I needed to delete the cache and it started working again like a charm.

To find the cache location poetry config --list

delete the cache directory containing the private repository. Or run poetry cache clear repo-name --all

delete the virtual-env from your project run poetry install/update again it will work.

Please Have a look https://github.com/python-poetry/poetry/issues/1631 I think that’s the reason why we are having this problem at first place.

I get the same issue too with 1.2.0a2 if I install via the new install_poetry.py script. If I install poetry into a venv with pip install poetry==1.2.0a2 I do not get this issue somehow. But I then get warnings when using poetry:

SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.

And I do not use a secondary repo at all.

poetry-core 1.0.6 has been released, this issue is still present.

I use a secondary repo and I’m having this issue with 1.2.0:

• Installing mypackage (0.10.0): Failed

  RuntimeError

  Retrieved digest for link mypackage-0.10.0-py3-none-any.whl(md5:f1c63397a2b6718593315a06a0a73579) not in poetry.lock metadata ['sha256:d1d3de1bcf913df45c3b8a1d5b1d8eaba3207140785b733b24568552b192e4ce', 'sha256:e887c6b1b3d15157a167a7c3d50fce03d31a7ae9df73c647cc24d1f7e7bf2fbf']

  at ~/.local/share/pypoetry/venv/lib/python3.9/site-packages/poetry/installation/chooser.py:144 in _get_links
      140│
      141│             selected_links.append(link)
      142│
      143│         if links and not selected_links:
    → 144│             raise RuntimeError(
      145│                 f"Retrieved digest for link {link.filename}({h}) not in poetry.lock"
      146│                 f" metadata {hashes}"
      147│             )
      148│

reverting back to 1.1.15 solved the issue.

somehow, if you switch to the poetry-1.1.9 it will also fix the issue, even with the poetry-core-1.0.5. so, apparently, the issue is not with the poetry-core but with poetry itself, as it passes the wrong argument.

Still present in 1.0.7

somehow, if you switch to the poetry-1.1.9 it will also fix the issue, even with the poetry-core-1.0.5. so, apparently, the issue is not with the poetry-core but with poetry itself, as it passes the wrong argument.

Using poetry==1.1.9 without locking poetry-core to 1.0.4 does not fix it for me.

pip install poetry-core==1.0.4 is a temporary solution, had the same issue and it worked for me. Releasing private pypi package to gemfury. ` AttributeError

‘Link’ object has no attribute ‘name’

at /usr/local/lib/python3.9/site-packages/poetry/installation/executor.py:620 in _download_link

  615│                 ).hash()
  617│             )
  618│             if archive_hash not in {f["hash"] for f in package.files}:
  619│                 raise RuntimeError(
→ 620│                     "Invalid hash for {} using archive {}".format(package, archive.name)
  621│                 )
  622│
  623│         return archive
  624│`

I’ve opened a PR to generate this error message properly: #4212.

I’m experiencing the underlying issue in Poetry 1.2.0a1. I’m installing a package from a private Gemfury repository.

Gemfury’s legacy PyPI API returns only md5 hashes, not sha256 hashes. (By comparison, JFrog had a similar limitation until recently.) My lockfile contains only sha256 hashes, hence the mismatch error at install time.

In contrast, Poetry 1.1.7 works fine. A lockfile generated by 1.1.7 also contains the sha256 hashes, yet installation works fine.

Is it possible this is a regression caused by the changes in #2958?

This issue describes an attribute error in code that no longer exists, closed is definitely the right state for it.

You want #6301 maybe

Is this related to #4523?