skip get_requires for setuptools projects

[jameslamb]

fixes #39

As of this change rapids-build-backend will do the following when asked to build a wheel for a project using setuptools as its build backend:

• skip running setuptools.build_meta.get_requires_for_*() methods
• raise an error if it appears that the project has a setup.py that is passing setup_requires to setuptools.setup()

See #39 for a lot more details.

Notes for Reviewers

How I tested this

Added new unit tests here.

Built from source on this branch in rapidsai/ucx-py#1044 and saw CI pass...things work as expected, based on a quick scan of the logs there. (ignore the failing docs build there, that'll pass once we've published new rapids-build-backend wheels).

(ucx-py build link)

Thoughts on releasing

This change is "breaking" in the sense that it changes the behavior in a user-visible way, but not in the practical sense... there are 0 projects currently using rapids-build-backend that should be affected by this change.

So I think that we should release rapids-build-backend with this change in it as v0.3.1, not v0.4.0, to avoid a round of PRs to update the existing rapids-build-backend pins across projects already using it.

[vyasr]

Rather than creating a new examples directory for tests, can you reuse the existing templates? I would expect the existing dependencies.yaml and pyproject.toml files to work out of the box (although maybe you'll have to generalize dependencies.yaml, not sure). Adding setup.py there will allow you to also parametrize the tests so that you can test packages with setup.py in more scenarios (e.g. with setup_requires, setup_requires in a comment, etc).

[vyasr]

A bunch of nitpicking on my part, but overall this looks ready to me.

[vyasr]

Not a big deal, but this parametrization is hard to read. You might consider doing something like creating a list of multiline strings or something and then using zip(contents, errors) instead.

[jameslamb]

Yeah you're right. I just tried reformatting it by removing "should this raise an error?" from the parameterization completely and splitting it into 2 tests (one with cases that shouldn't result in an error, one with cases that should).

I think it's a lot easier to read and understand now:

[vyasr]

Minor nit: This is my fault for creating this pattern (I assume it was me), but on second read it's certainly a bit strange to use the same template args for all the generate_from_template calls. It would probably be cleaner to have just the necessary ones for each file.

[jameslamb]

Yeah as far as I can tell, there's 0 sharing of template arguments across the files, so it should be possible to instead do something like:

template_values = {
   "pyproject.toml": {
       "name": "something",
       "build_backend": "setuptools.build_meta
   },
   "dependencies.yaml": {
       "dependencies": {
            "cu11": ["cupy-cuda11x>=12.0.0"],
            "cu12": ["cupy-cuda12x>=12.0.0"],
        }
   }
}
generate_from_template(package_dir, template_args)

Where the top-level keys are the files to use and the dictionary passed after each one is the template arguments.

However... I'd rather not do that refactoring as part of this PR. I don't think that's THAT much better than the current state, at least with the small number of tests we currently have here.

[vyasr]

The three new tests are similar enough that I suspect you could convert them to a single parametrized test fairly easily, but I could be wrong.

[jameslamb]

I think the sets of assertions are different enough, and the setup before that small enough, to justify separate test cases.

They could get put into one parameterized test but that test would end like this:

if first_thing_being tested:
   # assertions
elif second_thing_being_testing:
   # other assertions
else:
   # third set of assertions

I think it's a little easier to follow the logic by keeping these new tests as separate cases.

[jameslamb]

I pushed a new commit to the ucx-py PR that's building from this branch (rapidsai/ucx-py#1044), to test that this is still working. It is: https://github.com/rapidsai/ucx-py/actions/runs/9469286911/job/26087647602?pr=1044

[jameslamb]

I just snuck a --file_key to --file-key change for rapidsai/dependency-file-generator#89 on here too, to get one closer to finishing that work. Think that's small and non-controversial enough to include here.

[jameslamb]

Alright I think all the comments have been addressed, so gonna merge this and keep moving forward. Thanks everyone!