pypirc: stipulate UTF-8 encoding #1980
Open
+7
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a kind of interesting/nuanced thing, and I don't know if this PR is actually the right approach 😅 -- I'm opening it for discussion!
Context:
.pypircwas never PEP'd; it was seemingly grandfathered in as a distutils implementation detail that gets respected by twine and flit (and perhaps others?). As a result, there's no stipulation as to what charset a.pypircshould be encoded with.In practice this is mostly a non-issue: most users will default to UTF-8, or in the worst case they'll use whatever system character encoding Python picks and hopefully their consuming tool will too. However this does unfortunately break down sometimes, like with pypa/twine#1268 recently.
I think the best fix here is just to rip the bandaid off and stipulate that
.pypircfiles should be UTF-8, especially since upcoming Python versions will use UTF-8 in a blanket fashion by default. I've gone with "should" instead of "must" since twine does make an effort to parse using the system charset, but this is a fallback we'd probably like to eventually remove. I'm not sure what flit does, but "should" also felt appropriate given that it's entirely open-ended at the moment 🙂Open questions:
.pypircis (1) kind of a legacy component anyways, and (2) never went through a packaging PEP (AFAICT). However, I'd like to hear if others feel otherwise.📚 Documentation preview 📚: https://python-packaging-user-guide--1980.org.readthedocs.build/en/1980/