Revert erroring when readme content does not render #4099
Conversation
tests/unit/forklift/test_legacy.py
Outdated
| @@ -919,6 +919,7 @@ def test_fails_with_invalid_names(self, pyramid_config, db_request, name): | |||
| "for more information." | |||
| ).format(name) | |||
|
|
|||
| @pytest.mark.xfail(reason='https://github.com/pypa/warehouse/issues/4079') | |||
There was a problem hiding this comment.
black will want these to be " instead of ', though that landed while I was away :-D not sure if we enforce it in linter yet.
| description_content_type = form.description_content_type.data | ||
| if not description_content_type: | ||
| description_content_type = "text/x-rst" | ||
| rendered = readme.render( |
There was a problem hiding this comment.
import of warehouse.utils.readme on line 55 no longer used.
|
Looks like the original PR no longer cleanly reverts which is a bummer, so the comment out approach is OK to keep from losing too much context but isn't the standard approach. Do we know what the long term fix is for the issue? |
Not sure, I'll continue investigating. |
|
@theacodes perfect. if you can push the lint issue fixups, we'll get this merged and deployed to unblock publications. |
|
delinted |
|
It seems to me like this is working as expected, and that the issue lies with either twine, wheel or setuptools versions being old and not supporting Metadata 2.1, or users using distutils instead of twine to upload. |
|
Yes, it's working as expected but having unintended consequences. I'd
prefer to err on the side of allowing uploads while we sort this out.
…On Tue, May 29, 2018, 1:50 PM Dustin Ingram ***@***.***> wrote:
It seems to me like this is working as expected, and that the issue lies
with either twine, wheel or setuptools versions being old and not
supporting Metadata 2.1, or users using distutils instead of twine to
upload.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4099 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAPUc9DmtVD0MGn5_7Ghf309BPzzfFp5ks5t3bSqgaJpZM4USDky>
.
|
|
gonna merge up to unblock users. any opposition @di? |
|
On closer inspection I agree with @di that this is a metadata/client issue. I'm not sure about the revert given that, but do see at least one scenario where the wheel upload worked but sdist did not. This still seems like it could be a client issue but is confusing enough that it probably requires further investigation before shipping the validation. |
I'm experiencing this using Travis-CI auto deployment feature. According to the logs Travis-CI is using
those look new enough but I'm not sure if Travis-CI is calling See https://travis-ci.org/pyoceans/erddapy/jobs/385360404#L1591 Thanks to this PR the deployment worked as expected: https://travis-ci.org/pyoceans/erddapy/jobs/385409165 (But the Markdown description is not rendering as expected 😬) |
Right, this is what we were trying to prevent. After taking a look at this, I'm fairly sure the problem is either out of date dependencies or using |
I get the same if I upload manually with all tools updated and twine :-/
That is fine IMO as long as the upload is not blocked. Thanks everybody for the info and the quick action! |
This temporarily disables the validation added #3980 which is preventing several users from uploading packages (#4079).