Fix building packages with backend-path in pyproject.toml

[takluyver]

All that's needed is passing the field from pyproject.toml through to Pep517HookCaller.

Closes gh-6599

[uranusjr]

Would this be a good chance to refactor the return value into a named tuple? An optional two-tuple is kind of OK, but I’m starting to feel a tiny bit uncomfortable to read Optional[Tuple[List[str], str, List[str]]]..

[takluyver]

Sounds reasonable. Shall I call it BuildsystemDetails?

[uranusjr]

I’m thinking BuildSystemDetail is probably better (capital S) since build-system is two words in pyproject.toml. Otherwise LGTM.

[takluyver]

Was detail (singular) a deliberate change? I was following PackageDetails elsewhere in the code to prefer the plural.

[chrahunt]

A few minor comments. I think it's okay that we're leaning a bit on pep517 for the more thorough testing of this feature, but I would add an integration test or two (for a local project using backend-path and a dependency) since there's going to be a lot of change in the coming months in InstallRequirement.

[takluyver]

I added a test which uses a local backend and an external dependency together.

[chrahunt]

For the additional test I was thinking more along the lines of invoking pip as a sub-process to install a pep517 project, similar to this test, and then validating that the install succeeded via the in-tree backend. The backend could write a file (path provided via environment variable) to be checked in the test and then delegate to the equivalent functions in setuptools.build_meta.

This helps us guard against regressions caused anywhere else in the currently tangled interactions between InstallRequirement and the classes and functions that operate on it.

[takluyver]

I've added a higher-level test as @chrahunt requested, but I've left the namedtuple in place for the moment. I'll change it again if it looks like there's a consensus for another option.

[pfmoore]

Thanks for addressing this issue @takluyver!