Enable forwarding warnings from subprocess to the caller

[pradyunsg]

This would be a reasonable mechanism to surface deprecation/build-related warnings from underlying build-backends to the build-frontends, which can then surface them to users appropriately.

This would likely involve some way to capture and communicate the log messages back to the calling process; ideally with the ability to show the warnings without waiting for the end of the build-backend subprocess.

[pradyunsg]

To be clear, I'm thinking of warnings.warn-style warnings.

[pradyunsg]

FYI: I've started exploring implementing this and figuring out what this should look like.

[pradyunsg]

Adding a x-ref to https://discuss.python.org/t/adding-a-mechanism-to-forward-user-facing-information-from-build-backends-to-build-frontends/28106 where this approach will (hopefully) be discussed more broadly.

[pradyunsg]

Hmm... I came here to close this now that #213 is merged but it looks like this might actually need a PEP or something to make things clearer?

@notatallshaw Any concerns if I revert #213 and we resurrect that discussion? I might have missed context from a more recent discussion, if there is one.

[notatallshaw]

@notatallshaw Any concerns if I revert #213 and we resurrect that discussion? I might have missed context from a more recent discussion, if there is one.

The comment here suggested this would just need a spec clarification not a PEP: pypa/packaging-problems#558 (comment)

There was some recent discussion in this thread: https://discuss.python.org/t/how-can-build-backends-avoid-breaking-users-when-they-make-backwards-incompatible-changes/85847

My motivation here is to help build backends communicate with users to reduce the chance of unexpected failures, and I don't really have an opinion on the spec, I haven't read it in detail. But if you're not comfortable with it I am motivated to do whatever steps are required until you are.

[pfmoore]

The comment here suggested this would just need a spec clarification not a PEP

So that means it needs (1) a dedicated thread on Discourse proposing the change and establishing community consensus that it's ok as a spec change, and (2) the actual spec change having been made.

I agree with @pradyunsg - let's revert until that has happened.

[notatallshaw]

So that means it needs (1) a dedicated thread on Discourse proposing the change and establishing community consensus that it's ok as a spec change, and (2) the actual spec change having been made.

I was being optimistic and hoping this had already been done since your post in 2021.

I started take a look at updating the specifications, but as best as I can tell PEP 517 has never been added to: https://packaging.python.org/en/latest/specifications/

So as a first step should I raise a PR that adds PEP 517 to the specifications and then another PR that updates the PEP to link to the relevant specifications page (as I see with many other packaging PEPs)?

[pfmoore]

Wow, that was back in 2021? I hadn't even noticed the date 🙁

My general impression is that build backends don't tend to engage much with the standards process. That may be because PEP 517 is actually pretty good, and there's little need for change (optimistically, I hope that is the case). But it is surprising¹ to me that setuptools identified this need back in 2021, but then didn't do anything to move it forward, leaving us in the situation now that they can't get their deprecation warnings out to users...

At some point, someone needs to get PEP 517 added to the specs, yes. If it's something you are willing to do, then go for it. Although the revision process - see below - does allow for updating specs where the PEP is still the reference documentation, so moving PEP 517 into the specs isn't a blocker here.

The actual process for making a change is here. I don't think what's being suggested here comes under the classification of "readability improvements that don’t affect software interoperability", unless we're talking about nothing more than a description of the fact that build backends might issue warnings, and frontends might choose to catch them. But once we move into the territory of suggesting that frontends should (or even must) display warnings, that's more than just readability.

At that point, the actual proposal should be raised on Discourse. That's not simply a broad statement of intent ("we should expose backend warnings"), it's a specific proposal for new wording, which will (for example) be explicit about whether backends can assume that warnings will be displayed, and what frontends have to do. The discussion can result in changes to the wording, or even completly new proposals, but we have to start with something specific. It's not a PEP as such², but it does need to be similarly precise. The process isn't 100% clear on what is needed for a proposal to be "approved as a text-only change", but I've always assumed it requires community consensus, with the PEP-delegate (me) having final say that an appropriate consensus has been reached. If we don't get consensus, the proposal needs to go to a PEP or be dropped.

Personally, my view is that a change saying that frontends should provide a mechanism to allow users to see warnings issued by build backends would be acceptable. Saying that frontends which provide such a mechanism should display backend warnings by default would be more controversial, but might still be OK. But it would still mean that backends cannot rely on warnings being seen by default, and must be prepared for the possibility that warnings don't get shown (i.e., what we have now). Anything that requires front ends to display backend warnings feels like it's in PEP territory to me. But that's just my personal feel. Community consensus could be different - the only way to know is to make a proposal.

I will note that the mechanism here (as implemented in #171) is perfectly OK with no spec change. It's just that it counts as "implementation defined behaviour" currently. I don't know for certain what this project's position is on adding implementation-specific mechanisms, but I feel that as the reference implementation, it should be very cautious about doing so. Similarly, I know that pip's position (as a consumer) is generally that we don't add feaures unless they are backed by a standard. So the need for a spec change is more to do with project policies than because the current spec disallows this mechanism.

Footnotes

1. And a little disappointing, if I'm honest. ↩

2. Although it can turn into one if necessary. ↩

[pradyunsg]

Hmm... Thinking about this a bit more (and given the context of the more recent threads and Al that), I'm inclined to have us move forward here.

I'm happy to commit to updating PEP 517 spec / driving those discussions when we come around to adding it to the standards section on packaging.python.org.

AFAICT, no one has any blocking concerns with the actual logical change here and our concerns are mostly that we're deviating from the norms here / haven't done all the dotting the i-s, crossing the t-s.

[pradyunsg]

At that point, the actual proposal should be raised on Discourse.

More than what was discussed in https://discuss.python.org/t/adding-a-mechanism-to-forward-user-facing-warnings-from-build-backends-to-build-frontends/28106?

[notatallshaw]

I would have liked to give a more detailed reply , but it would take me some time and I'm not likely to have that time soon.

So in short, I was not planning for the spec to say that front end installers are required to display warnings, my original thought was to only say that they MAY display warnings, and that they MAY make that choice on a per distribution basis. But I am happy to for the spec to say that they SHOULD display warnings.

In a practical sense it is up to pyproject-hooks to forward on the warnings, and it would be up to pip to suppress them on a per distribution basis, based on whatever criteria pip ends up thinking is a good UX.

[pfmoore]

My only concerns are:

1. Are build backends OK with not being able to guarantee that warnings will be seen by users?
2. What is uv, in particular, going to do? They don't use this library, and they may have problems with accessing Python warnings.

The latter is only about the broader picture of how useful this will be in practice for backends.

Neither of these are blockers for adding this, either here or in pip.