Provide a way to signal an sdist isn't meant to be built?

[kknechtel (Karl Knechtel)]

@pf_moore

This is indeed an important point. For example, I routinely have Visual C++ installed on my system. So for me, “needs a C compiler” isn’t a blocker. But (for example), “needs the GMP library” is a blocker. Expecting anyone other than me to make that distinction is unreasonable. Conversely, though, a system that says everything that’s not pure Python is “hard to build” makes things harder than they need to be for me.

That’s the primary motivation behind my proposal, actually. (But implementing it does seem like more work than I could handle at the moment, and certainly more than I could expect of others…)

@mwichmann

At the cost of a bit of a delay, I bet package authors find out pretty quickly - they’ll get a flood of issue reports like “I can’t install your package on Windows, here, look at this hundred-line mess it gave me.”

They get a sense in aggregate, but this doesn’t help individual users. And honestly, they probably usually have a pretty good idea of that aggregate sense to begin with.

@oscarbenjamin

Going with PEP 725 is fine but it basically means not doing anything about this now and leaving it unresolved for an indeterminate time.

… And that’s why I had the bit about splitting up the PEP 725 implementation, so there could be human-readable descriptions first and automated attempts to locate dependencies later (much later, probably).

Although, you have a point that there’s a difference between knowing whether you most likely can build something locally, and deciding whether you want to make the attempt. Especially without a good idea in advance of how long it might take.