Call for clarification: acceptable values for build-system.requires in pyproject.toml

[webknjaz]

Environment

• pip version: 19.0.3
• Python version: 3.7
• OS: GNU/Linux

Description

It's not clear nor is clearly specified by PEP518. But I was having a need to have an in-tree build back-end.
So I've hacked it via installing with a relative path.
And it works!
Yet, @pradyunsg has pointed out that the way I used probably doesn't conform to PEP 508.
So I tried some other ways to point to the in-tree distribution. And those didn't work.

How to Reproduce

(this works)

[build-system]
requires = ["./build-aiohttp", ]
build-backend = "build_aiohttp.api"

# not yet supported, so it doesn't influence anything, it's for forward-compat:
backend-path = "./build-aiohttp"

But if instead of "./build-aiohttp" in requires I try any of "file://build-aiohttp", "file:///./build-aiohttp", "build_aiohttp @ file://./build-aiohttp", "build_aiohttp @ file:./build-aiohttp" pip fails to recognize those as installables.

Expected behavior

I don't know what to expect. The method which works seems to be undefined in PEPs so I probably shouldn't rely on it.

Pip may either decide to improve the filtering of requires option or document it being permissive...

P.S. Oh and, by the way, I was able to test my other PEP517 backend outside of the project tree via

[build-system]
requires = ["../fortunate_pkg"]

so this relative path feature proves to be quite useful for development/debugging purposes.

[pfmoore]

In-tree backend support was recently added to PEP 517. It's not yet supported in pip, however.

[webknjaz]

Hi Paul, I do know that. My question is about whether it's legal to put a relative path in requires.

[pfmoore]

Ah, sorry, my misunderstanding. I don't believe so, PEP 518 states what can go in requires:

This key must have a value of a list of strings representing PEP 508 dependencies

So they aren't paths at all, and if pip is accepting paths, that's wrong.

[cjerdonek]

Here is where pip's validation logic is currently (it only checks that it's a list of strings):

pip/src/pip/_internal/pyproject.py

Lines 89 to 95 in 54b6a91

	# Error out if requires is not a list of strings
	requires = build_system["requires"]
	if not _is_list_of_str(requires):
	raise InstallationError(error_template.format(
	package=req_name,
	reason="'build-system.requires' is not a list of strings.",
	))

[pfmoore]

I'm inclined to describe this as "user error" - which is not to say that pip couldn't give better messages, but it's the user's responsibility to supply valid input. I don't really think we need to do full PEP 508 validation here.

The odd sort-of-works result is probably because pip accepts more than just PEP 508 dependencies as "things to install", so this is arguably "behaviour undefined by the PEP that triggers an implementation defined result". The classic Undefined Behaviour nasal demons case ;-)

[webknjaz]

Right, I'm just trying to decide whether to rely on it. Because, if it turns out broken in the next version, then it would affect already published sdists.

[chrahunt]

@webknjaz you can use intreehooks:loader as was done for flit here. This should continue to work regardless of what pip does.

[pradyunsg]

I'm inclined to say let's actually abort in this edge case.

I don't want people trying things they shouldn't and it sort-of working.

[chrahunt]

Agreed, especially since this use case is covered by intreehooks and (soon) backend-path.