On Thu, Jul 6, 2017, at 06:19 PM, Donald Stufft wrote: > I *think* if we had some way to signal expected failure vs unexpected failure > this would be reasonable to me. I wouldn’t just want it to flat out be any > failure, but if we used Nathaniels NotImplemented idea or something similar > to indicate that “hey, I can’t build an sdist here for expected reasons” > compared to “Hey I tried to build the sdist, but something went wrong” I > think that would be workable. I'd prefer that it catches any failure, prints a warning and carries on to the fallback, but I can see where you're coming from, and I can live with this if I can trigger the fallback when the VCS is not available. > A similar-ish scenario is I hope to in the future be able to start validating > the rendering of long_description on PyPI on upload, and rejecting for > invalid syntax, because while readme_renderer exists and people can use it > (and it lets them detect problems earlier on) forcing all uploads to PyPI to > essentially have their long_description checked completely side steps that > class of problems from reoccurring. I'm with you on this, and flit actually already checks this before upload (though it's a warning, rather than an error). But the difference in this case is that it's never an inconvenience for a downstream user - it only affects the person uploading to PyPI, who can presumably fix it. Enforcing things when installing from source affects users who can't fix any issues it highlights. Thomas
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
