editable installs ignore exceptions as of v64.0.2

[2bndy5]

I have a custom subcommand that I'm using to generate pkg data. I'm also using an env var to instigate a "dirty" build. But this is where I need to raise an exception during an editable install: If the dirty option is asserted and the would-be generated pkg data does not exist, then I would like to prevent the build from completing properly.

As a workaround, I'm pinning to setuptools>=64,<64.0.2.

Is there a more conventional approach that I'm missing? I noticed the src names Aug 2023 as the date of repealing the _safely_run() function:

setuptools/setuptools/command/editable_wheel.py

Lines 287 to 322 in cd9c6a4

	# Also remove _safely_run, TestCustomBuildPy. Suggested date: Aug/2023.
	build: Command = self.get_finalized_command("build")
	for name in build.get_sub_commands():
	cmd = self.get_finalized_command(name)
	if name == "build_py" and type(cmd) != build_py_cls:
	self._safely_run(name)
	else:
	self.run_command(name)
	def _safely_run(self, cmd_name: str):
	try:
	return self.run_command(cmd_name)
	except Exception:
	SetuptoolsDeprecationWarning.emit(
	"Customization incompatible with editable install",
	f"""
	{traceback.format_exc()}
	If you are seeing this warning it is very likely that a setuptools
	plugin or customization overrides the `{cmd_name}` command, without
	taking into consideration how editable installs run build steps
	starting from setuptools v64.0.0.
	Plugin authors and developers relying on custom build steps are
	encouraged to update their `{cmd_name}` implementation considering the
	information about editable installs in
	https://setuptools.pypa.io/en/latest/userguide/extension.html.
	For the time being `setuptools` will silence this error and ignore
	the faulty command, but this behaviour will change in future versions.
	""",
	# TODO: define due_date
	# There is a series of shortcomings with the available editable install
	# methods, and they are very controversial. This is something that still
	# needs work.
	)

But the comment below in _safely_run() seems to contradict the Aug 2023 date:

TODO: define due_date

[abravalheri]

Hi @2bndy5 please note that "suggested due date" is not the same thing as a final, definite, due date exposed to the final users... so I don't see any contradiction here.

Is there a more conventional approach that I'm missing?

Not that I am aware, but please don't rely on the fact that a specific kind of exception is raised. It is not part of the public API that setuptools will let exceptions to pass through without attempting to use exception handlers...

If you need to handle an exception maybe the best option is to do it directly whenever/wherever it occurs instead of waiting for it to propagate through the call stack...

[2bndy5]

I'm not trying to handle any exception. I'm trying to prevent a bad build. The pkg data I generate depends on certain files to exists that aren't included in sdist, namely svgo config and package.json. I would expect a FileNotFoundException to exit the build early but nope.

Just to be clear, I'm not questioning when this exception ignoring behavior will revert. I'm questioning the decision to ignore exceptions in the first place. The commit description offers no rationale other than the originating PR's description which seems to reference an edge case (I don't really understand the dialogue in #3501). The API I'm using is publicly documented, but I didn't see any mention of silencing/ignoring exceptions. I looked at PEP660, but it is long and either vague in some places or extremely technical (beyond my own understanding) in other places.

This comment seems a bit hostile on first read, but I'm really just confused and frustrated. Thank you for the quick initial response.

[abravalheri]

The pkg data I generate depends on certain files to exists that aren't included in sdist, namely svgo config and package.json. I would expect a FileNotFoundException to exit the build early but nope.

Hi @2bndy5, I don't think I will be able to help towards understanding why this expectation is not met without a better look on the source code. If you can provide a minimal reproducer maybe we can have a better look and discuss different options.

I'm questioning the decision to ignore exceptions in the first place. The commit description offers no rationale other than the #3506 which seems to reference an edge case (I don't really understand the dialogue in #3501).

The rationale here is pointed out by the docstring of the _run_build_subcommands and the exception message itself: 3rd party plugins expected an specific behaviour that is not viable under the light of PEP 660. Adding the temporary workaround has proven effective to solve the problems discussed in the original issue thread.

I am sorry if the issue thread, method docstring and exception message are difficult to understand, unfortunately I don't think I can do a better job on explaining than these 3 things together do. It is a complicated topic... But please don't interpret this as not making an effort to explain the rationale. We actually tried very hard! The fact that we added explanations into the docstring, exception messages, PR message and actively engaged in the issue thread are just proof that we make a big effort to communicate with the user base.

The API I'm using is publicly documented, but I didn't see any mention of silencing/ignoring exceptions.

Please note that I was not trying to imply that you are using a private API. I agree 100% that the command API is documented. However I think you are relying on a side-effect (bubbling up the exception without trying to handle it) that the API makes no public commitment about. It does happen that silencing exceptions and asking the user to double check if the editable installation succeeded is the best we can do to avoid certain disruption in the community.

The commit description offers no rationale other than the 3506 which seems to reference an edge case

Please note that, to some degree, we can also consider the problem that you are describing as an edge case (it even took longer to surface/be reported than 3506). Software projects sometimes face problems whose solutions are mutually exclusive...

I looked at PEP660, but it is long and either vague in some places or extremely technical (beyond my own understanding) in other places.

Please also note that PEP 660 (and its precursor PEP 517) are initiatives from the broader ecosystem and that setuptools also had to change to accommodate them. We all are doing our best to adapt to the new paradigm. This means that we can no longer treat setup.py as an executable script that works as a central point of coordination for the build process (now it is only a configuration file) and that command classes are reduced to "glorified callbacks".

In the context that setuptools has to expose an function-based API for building projects and try to be as backward compatible as possible, it is inevitable that some form of exception handling has to be implemented for certain situations.

This comment seems a bit hostile on first read, but I'm really just confused and frustrated.

No problems. If you can share some form of minimal reproducer, we can try to have a look think more about it.

[2bndy5]

We actually tried very hard!

Of this I have no doubt. I'm sorry if I sound unappreciative in this regard. The mere fact that the ecosystem has evolved so much in the last few years (and my arrogance of said evolution all the while) is what led to my confusion.

This means that we can no longer treat setup.py as an executable script that works as a central point of coordination for the build process (now it is only a configuration file) and that command classes are reduced to "glorified callbacks".

This was enlightening. I was operating under the assumption that an exception from setup.py would behave similarly to a normal module.

---

A reproducer would be easy since all I was doing was raising an exception from the SubCommand.finalize_options() (also tried SubCommand.run() with same result). But it sounds like my misunderstanding of custom command design led to a behavior that I found undesirable... Since opening this discussion, I've force-de-asserted my custom SubCommand's dirty option if the circumstance is not suitable; meaning I regenerate pkg data when using npm is possible and the generated pkg data doesn't exist. Now I'm able to pin sestuptools>=64.