TypeError: expected string or bytes-like object

[chhantyal]

Hi everyone,

I can't seem to figure why it is giving error, is it bug:

twine upload dist/*

Uploading distributions to https://upload.pypi.org/legacy/
TypeError: expected string or bytes-like object

I created ~/.pypirc with creds. Also tried Env Vars, no luck :(

[di]

@chhantyal What version of twine do you have? What distributions are you trying to upload and how were they built? Any other steps for us to be able to reproduce?

[sigmavirus24]

Also twine --version is useful information to have

[chhantyal]

Sorry I was in hurry yesterday. Here is more details:

Platform: OSX 10.12.6
Python 3.6

$ twine --version

twine version 1.9.1 (pkginfo: 1.4.1, requests: 2.18.4, setuptools: 36.5.0,
requests-toolbelt: 0.8.0, tqdm: 4.19.5)

I am trying to upload this package: https://github.com/chhantyal/parquet-cli

• python setup.py bdist_wheel --universal
• python setup.py sdist
• twine upload dist/*

[chhantyal]

I am not sure what is the problem, I cloned this repo and ran from source. It worked.

python twine/__main__.py upload path/to/dist/*

However, develop command of same source still gives above error.

[sigmavirus24]

Can you also include the version of wheel you've installed. I suspect this may be related to #341

[chhantyal]

Sure, here is wheel version:

$ wheel version

wheel 0.31.0

[pior]

Same thing for me:

$ twine upload dist/*
Uploading distributions to https://upload.pypi.org/legacy/
TypeError: expected string or bytes-like object

$ pip --version
pip 9.0.3 from /Users/piorbastida/.pyenv/virtualenvs/shopify_python/3.6.4/lib/python3.6/site-packages (python 3.6)
$ pip show wheel | grep Version
Version: 0.31.0
$ pip show twine | grep Version
Version: 1.11.0

[sigmavirus24]

@chhantyal @pior does this happen with the wheel alone or with the sdist alone? That'll help narrow things down

[pior]

@sigmavirus24 It happens with both, I tried them separately.

[Amnesthesia]

Same here. It's been working for weeks, but started breaking a couple of days ago on our CI server

[sigmavirus24]

Can you untar the sdist and paste the PKGINFO (or PKG-INFO) file into a comment here? I suspect this is related to gh-341

[pior]

Metadata-Version: 2.1 for me

[chhantyal]

Metadata-Version: 1.1
Name: parquet-cli
Version: 1.0
Home-page: https://github.com/chhantyal/parquet-cli
Author: Nar Kumar Chhantyal
...
License: BSD 3-Clause License

[sigmavirus24]

Interesting. @chhantyal we have your pkginfo version (1.4.1). @pior can you give us the full output of twine --version?

[sigmavirus24]

If one or both of you could email me the files that aren't working that'd be useful too. My email is on my profile

[pior]

twine version 1.11.0 (pkginfo: 1.4.2, requests: 2.18.4, setuptools: 39.0.1,
requests-toolbelt: 0.8.0, tqdm: 4.21.0)

In case you need the full PKG-INFO:

Metadata-Version: 2.1
Name: shopify_python
Version: 0.4.5
Summary: Python Standards Library for Shopify
Home-page: http://github.com/shopify/shopify_python
Author: Shopify Data Acceleration
Author-email: [email protected]
License: MIT
Description: UNKNOWN
Platform: UNKNOWN
Classifier: Development Status :: 2 - Pre-Alpha
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: MIT License
Classifier: Natural Language :: English
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 2
Provides-Extra: dev

[chhantyal]

Actually it is working for me now, with updated twine:

twine --version
twine version 1.11.0 (pkginfo: 1.4.2, requests: 2.18.4, setuptools: 39.0.1,
requests-toolbelt: 0.8.0, tqdm: 4.21.0)

I was using 1.9.1 earlier.

[Amnesthesia]

Same here, upgrading to 1.11 seems to fix this

[Akuukis]

I had the same issue. Found out that this was confusion between python3.6 and python2.7 packages. My pip pointed to pip3.6 so that pip list nor pip uninstall twine unexpectedly did not found python2.7's twine which sat in my PATH nevertheless. Uninstalling python2.7 twine solved the problem. Found with sudo find / -name twine

[asottile]

I've provided a more useful stacktrace in #348 -- seems to be a bad interaction between twine and setuptools from the looks of it

[scottbelden]

Like others, I was using 1.9.1 and upgrading to 1.11.0 resolved it for me.

[martinohanlon]

I started receiving this error after I updated pip from 9.0.1 to 10.0.1.

Upgrading twine to 1.11.0 resolved the problem.

[oroulet]

same here in ubuntu 18.04. updating using pip solves issue

[pmart123]

I am getting a similar issue when I try and use twine to upload a package. My twine version is:

twine version 1.8.1 (pkginfo: 1.3.2, requests: 2.18.4, setuptools: 35.0.2,
requests-toolbelt: 0.7.0, clint: 0.5.1)

pip version 10.0.1

Python 3.6.4 :: Anaconda custom (x86_64)

Looking at my package info file, my metadata version is Metadata-Version: 2.1. If this is the reason the package will not upload, is there an easy way to force the metadata version to be lower when building the source code and wheel? Thanks.

[sigmavirus24]

@pmart123 the better choice is to use the newest twine version as others above have. I don't believe setuptools/wheel allows you to specify the metadata version

[pmart123]

@sigmavirus24 Thank you for the suggestion. I just upgraded Python to 3.6.5 and it seemed to resolve the issue.

[eliasdabbas]

I'm going through the same issue, tried the various approaches mentioned here, but still it's not working.

This might be a stupid question, but I'm not sure why I'm getting two different versions of twine when I check from the command line vs when I check from within Python:

~/
> twine --version
twine version 1.9.1 (pkginfo: 1.4.1, requests: 2.18.4, setuptools: 36.6.0,
requests-toolbelt: 0.8.0, tqdm: 4.14.0)
~/
> python
Python 3.6.5 |Anaconda custom (64-bit)| (default, Mar 29 2018, 13:14:23) 
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import twine
>>> twine.__version__
'1.11.0'

Thanks!

[sigmavirus24]

@eliasdabbas one thing you might try is:

cat $(which twine)

And

> python
>>> import twine
>>> print(twine.__file__)

[eliasdabbas]

Thanks @sigmavirus24

twine.__file__ shows the file that includes __version__ = "1.11.0", which seems to be the latest version.

and cat $(which twine) gives this output:

#!/Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6

# -*- coding: utf-8 -*-
import re
import sys

from twine.__main__ import main

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(main())

Not sure how that might help? Sorry!

The last comments suggest to upgrade to Python 3.6.5 and twine 1.11, which I have both already but I'm still getting the same error.

TypeError: expected string or bytes-like object

running twine --version shows version 1.9.1, which is different from what twine.__file__ shows. Does that mean there is something wrong somewhere?

Thanks.

[sigmavirus24]

I can't help you without the output of twine.__file__ Normally, that should line up with:

/Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6

From the output of cat $(which twine) except that in this case, I expect them to be vastly different. You can confirm which python is pointing to the right thing and if it isn't, I'd suggest checking your PATH as well. Regardless, this issue certainly isn't the right place to be debugging your broken installation.

[eliasdabbas]

Thanks it might be an installation issue. It's just that I was getting the same error message mentioned in the title.
Anyway I was able to upload with flit, and it looks fine. I'll check if I have any installation issues.
Thank you.

[oscar6echo]

FYI

I had the same error a very similar situation as @eliasdabbas with the same 2 versions.

I was in a conda env and noticed that the path is modified for python to that twine.__version__ points to version 1.11, conda list twine shows the same but for some reason command line twine did invoke version 1.9.1, although which twine did show a path leading under under my conda env.

Anyway updating twine in the root env solved it. And I could upload.

[benzkji]

@oscar6echo your comment saved me! uinstalling a globally installed twine made it using the one in the virtualenv! cheers!

[NimaBavari]

@Akuukis so, when I look up the version of twine in my python3, it shows 1.11.0, but when I look it up on ubuntu terminal, it shows 1.8.1. Aside from the issue in question persisting, I'm now more confused as if I'm using twine version 1.8 or 1.11.

twine --version

twine version 1.8.1 (pkginfo: 1.2.1, requests: 2.18.1, setuptools: 40.0.0, requests-toolbelt: 0.8.0, clint: 0.5.1)

But pip3 show twine | grep Version

Version: 1.11.0 License: Apache License, Version 2.0

Trying to upgrade twine from the ubuntu results with a message that it's at its newest version 1.8.1-2.

[tobegit3hub]

+1 for upgrading twine of 1.11 by pip install -U twine.

[di]

Closing this as the original issue seems to be resolved by upgrading Twine, and this issue is attracting unrelated problems about multiple Twine installations.

If you think you're having a related problem, please open a new issue.

[pablospe]

I had the same problem and solved it with:
python3 -m twine upload ...

Solution from:
https://stackoverflow.com/a/58267087/4562968