Closed Fogapod closed 3 years ago
Downgrading to twine 3.3.0 worked (random older version)
Can you show the output of twine --version
?
Here's mine (which is working on macOS):
% twine --version
twine version 3.4.1 (importlib_metadata: 3.7.3, pkginfo: 1.7.0, requests: 2.25.1, requests-toolbelt: 0.9.1, tqdm:
4.59.0)
Can you show the output of
twine --version
?
No, as I said, no commands work, not even twine --version
. Same error each time.
Ah, right. How about the output of python -m pip freeze
?
This is reminding me of https://github.com/pypa/twine/issues/760, where there was some odd behavior around multiple installations of importlib_metadata
. More troubleshooting commands from that issue:
type -a twine
type -a python
python -c "import sys; print(sys.executable)"
python -c "import importlib_metadata; print(importlib_metadata.version('importlib-metadata'))"
Have you tried installing Twine in a fresh virtual environment? That worked for me on macOS, using the same versions that you have installed:
% python3 -m venv venv-twine-774
% source venv-twine-774/bin/activate
% python3 -m pip install importlib_metadata==4.5.0 twine==3.4.1
% rehash
% type -a twine
twine is /private/tmp/venv-twine-774/bin/twine
twine is /Users/bhrutledge/.local/bin/twine
% twine --version
twine version 3.4.1 (importlib_metadata: 4.5.0, pkginfo: 1.7.1, requests: 2.25.1, requests-toolbelt: 0.9.1, tqdm:
4.61.2)
I will report back after Monday
debugging
$ type -a twine
twine is /home/eugene/.local/bin//twine
$ type -a python
python is /usr/bin/python
$ python -c "import sys; print(sys.executable)"
/usr/bin/python
$ python -c "import importlib_metadata; print(importlib_metadata.version('importlib-metadata'))"
4.6.0
venv
$ type -a twine
twine is /home/eugene/venv-twine-774/bin/twine
twine is /home/eugene/.local/bin//twine
$ twine --version
twine version 3.4.1 (importlib_metadata: 4.5.0, pkginfo: 1.7.1, requests: 2.26.0, requests-toolbelt: 0.9.1, tqdm: 4.61.2)
so it works inside venv, but refuses to work outside even after installing older version and reinstalling
EDIT: just noticed that my PATH was messed up, but after fixing it nothing changed:
$ type -a twine
twine is /home/eugene/.local/bin/twine
I'm stumped. I don't see anything out of the ordinary in the debugging info. I suspect there's an obscure conflict in your global Python environment, but I don't know how to track it down. @jaraco might have a suggestion, as a maintainer of Twine and importlib_metadata.
You might try:
python -m pip freeze > global-requirements.txt
python -m venv /tmp/test-venv
source /tmp/test/venv-bin/activate
pip install -r global-requirements.txt
And see if Twine still fails. If it does, you could try a binary chop of the requirements file to isolate the conflict.
Or, you could add import pdb; pdb.set_trace()
to /usr/lib/python3.9/site-packages/importlib_metadata/__init__.py
, above line 837 (which is the last third-party code to execute before the failure), look at the local variables, and trace it back up the stack.
However: I think this all points to why it's generally discouraged to install packages into your global Python environment. According to the PyPA's guide to installing stand alone command line tools:
Usually you want to be able to access these from anywhere, but installing packages and their dependencies to the same global environment can cause version conflicts and break dependencies the operating system has on Python packages.
Following the recommendation in that guide, you could pipx install twine
. Another common pattern is to install Twine as a development dependency in project virtual environments, along with other tools like flake8, black, etc
The error message indicates that importlib_metadata
is attempting to load the entry points for every package on the system, but encountering a package whose name is not text (probably None
). Thinking I'd seen this message before, I searched the importlib_metadata project for the error message, but I came up empty.
I suspect you have a package with invalid metadata (missing or corrupted).
I'd do this:
>>> import importlib_metadata as md
>>> dists = md.distributions()
>>> broken = [dist for dist in dists if dist.name is None]
>>> for dist in broken:
... print(dist._path)
... print('metadata length', len(dist.metadata()))
I'd then inspect the metadata in each path that's printed.
The issue isn't a twine issue. It just happens to affect twine because twine switched to using this newer importlib_metadata that happens to trip up on this environment. It's possible importlib_metadata should be more lenient in this case, but let's defer that consideration until we determine the cause.
>>> import importlib_metadata as md >>> dists = md.distributions() >>> broken = [dist for dist in dists if dist.name is None] >>> for dist in broken: ... print(dist._path) ... print('metadata length', len(dist.metadata()))
This produces error:
/home/eugene/.local/lib/python3.9/site-packages/-ravitia_talk-0.0.1.dist-info
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
TypeError: 'Message' object is not callable
Removing 2nd line, I get 2 broken packages:
/home/eugene/.local/lib/python3.9/site-packages/-ravitia_talk-0.0.1.dist-info
/home/eugene/.local/lib/python3.9/site-packages/-ip-19.0.dist-info
First is mine with broken name for some reason, 2nd one is pip with broken name as well.
Deleting them fixed twine. I have no idea when and why 1st letter of these packages got replaced by -
.
For future searchers, I had a similar related issue with scipy==1.9.3
that I solved with help from this thread. The following code pointed it out to me:
import importlib_metadata as md
for dist in md.distributions():
try:
_ = dist._normalized_name
except:
print(dist._path)
Still unsure why scipy was buggy, but I just downgraded to 1.9.2 and it works fine. Hope that helps someone.
Downgrading twine to 3.3.0 worked for me.
Your Environment
OS: Arch Linux
twine was installed using pip and worked before. I don't remember if I updated it before it broke.
The Issue
Nothing works. Any command raises exception: