-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PIP doesn't read setup.cfg in UTF-8, which causes UnicodeDecodeError #8931
Comments
distutils is a built-in module, you’ll need to file the issue against CPython instead. https://bugs.python.org/ |
Thanks for the quick reply. Interestingly, |
OK, it looks to me setuptools work arounds this issue on their own (pypa/setuptools#1180), is there any chance we do the same? I feel like I knew this probably is too much to ask, so feel free to do what you think is the best. |
Man, they basically re-implemented the whole thing. I’m not sure pip should be responsible to maintaining this implementation. Maybe we should just catch the parsing error and carry on pretending the file does not exist instead. pip does not actually need any of the data you mentioned above; it just reads distutils configuration. The usage is honestly quite niche, and I doubt many would even notice the difference. |
Oh yeah, totally agreed with you. If we don't need anything ciritial from cfg file (or, at least, in case it isn't, like global installation shown here), it's reasonable to just ignore the error. |
Today this issue bit me too in jaraco/configparser#58. |
Thinking about this more, this needs to be reimplemented eventually when pip migrates off distutils anyway, so we may as well do it right now. @jaraco Would it be a good idea if we extract setuptools’s config-parsing implementation into a standalone library that pip can vendor? |
In the case of distutils_scheme, there's currently an effort underway to deprecate distutils in which the distutils-schemes are being ported to the It's hard for me to say, but I'm a little reluctant to say that we should break out just the "parse config files" behavior into a separate library. On the other hand, that would eliminate one aspect of the dependency on distutils and limit the divergence from setuptools, so perhaps that makes sense. |
Is this still a thing in pip 20.3? |
Just tested, still broken here.
(Having the same |
Since distutils is deprecated and slated for removal in 3.12, maybe this is a good idea now? |
Yeah. The code path will eventually be removed altogether and replaced by an equivalent based on |
Also the new implementation does not currently contain the cfg parsing logic at all, and if no-one complains maybe we can just kill that feature entirely. |
What was it used for? |
It can be used to control certain distutils (and by extension setuptools) behaviours, like what directory to store intermediate objects during build, compiler options, etc. Very low-level, implementation-dependant stuffs, and some even in direct conflict with other pip options, so hopefully nobody is using them, but I’ve seen pip users use worse “features”. |
Why not a quick and dirty fix to suppress the error when it occurs and while at it, deprecate the code path, so if it is parsed and it contains settings that affect pip, raise warnings that it's going away, thereby detecting users who might be relying on it? |
I'm also okay with just removing the behavior and seeing who cries as long as there's a rapid response to bring the behavior back or an escape hatch to re-enable the behavior. |
The logic is buried deep in distutils and triggered when pip calls distutils to know where to install stuff into, distutils does not offer a way to disable the behaviour. So pip can’t just suppress the error since it needs those values to function, and the only way out of this (from what I can tell) is to remove reliance on those distutils values, which is what #9626 is going for. |
I was under the impression that it was this line that was raising:
Would it not be possible to wrap it in a try-except? |
We can, but the location behaviour would change in subtle ways when that fails 😟 But now that I think of it, maybe that’d still be a good enough stopgap before we purge distutils? Nothing would change if the parsing succeeds (which is most of the time), and the behaviour will “mostly work” when it fails, which might be good enough. |
What does "mostly work" mean? If I have, say:
in my |
That would not fail though. The parsing would only fail if the file contains content not decodable with the platform encoding. distutils also reads multiple config locations, including system-wide |
Yeah, I understand that. |
Environment
Description
When installing anything within a path that has a setup.cfg, pip will read it but fails at decoding if the file contains non-ASCII characters. The cfg file is proper UTF-8 but PIP doesn't open it as so. It tries to use "GBK" (my locale) and fails.
Related, but not the same issue: #8717 (this is caused by
pyvenv.cfg
)Expected behavior
It should read setup.cfg in UTF-8.
How to Reproduce
setup.cfg
file withpip install requests
Output
The text was updated successfully, but these errors were encountered: