Would love to see this merged soon :)

I have updated this to the latest main branch. Unfortunately I am somewhat at a loss as to how to update the tests to work.

The issue as far as I can tell is that although these changes appear to work perfectly well when combined with poetry (note that the downstream poetry test suite is running successfully: https://github.com/python-poetry/poetry-core/actions/runs/4127360352/jobs/7130470607), the need to have "packaging" as a dev dependency when using a build script (so that we can get the list of sys_tags that are actually present in the build environment) means that we need to run poetry update in order to make the dev dependencies available.

It seems that the integration tests in poetry-core are not working because the poetry update command is not called as part of the integration tests, and it appears that the update functionality is implemented directly in poetry (by invoking pip?) rather than being implemented in poetry-core, and I'm not sure where we would appropriately hook in to get these tests to work.

I've now rewritten the code to get the list of sys tags so that it just pip installs packaging into the build python environment before using it to get the list of tags. This seems better overall as it means that there are no breaking changes to pyproject.toml files (with the previous method, a dev dependency on packaging had to be added whenever a build script was specified).

Please could someone review this? We are still actively using the patched version of this code to do our binary wheel builds using poetry and it would be great to get it upstreamed.

I am not the best person to be looking at this, but the project is trying to move to not using pip to install packages. I wonder if it's possible to get access to the isolated build environment another way?

I am not the best person to be looking at this, but the project is trying to move to not using pip to install packages. I wonder if it's possible to get access to the isolated build environment another way?

Another option would be taking the sys_tags implementation (and all of its prereqs) from the packaging package and refactoring it into a stand-alone python script so we can just pass that directly to the build python for execution without actually installing anything into the environment.

I've now implemented a new idea after finding that there is a version of the packaging package in the _vendor directory of this repo, and in most cases it should be possible to point the build python to that version of packaging by setting PYTHONPATH when we invoke it.

This is working on linux and macos but is broken for some reason on windows (except for python 3.11 for some reason). Working on understanding the issues on windows now.

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

Am now preserving the environment when calling the build python interpreter (including appending our _vendor directory to PYTHONPATH rather than replacing it). This fixes the windows tests, as it seems the windows python installs prior to 3.11 require some setting in PYTHONPATH in order to be able to seed their PRNG.

All tests pass - could a maintainer please let me know if more is required to get this merged? Not sure who the appropriate contact is -- @radoering ?

I think I understand the reason for this and I'm not opposed so far. However, I want to hear the opinions of other maintainers before deciding if we want to introduce a new field wheel-tag-regex. I put this on my list for one of the next maintainer meetings. (A little heads-up: It might take some weeks until we discuss this.)

Apart from the general decision, I can already give some minor feedback. (It might make sense to wait for the general decision before working on that.)

If I understand correctly, retrieving the tags via a separate subprocess is not required if poetry-core is used as standalone build backend (and is executed in the build environment), but only if poetry-core is used as part of poetry (and is executed in poetry's environment)? If that's correct we should add it as comment in get_tags().

In poetry we already have a code snippet to get the tags: https://github.com/python-poetry/poetry/blob/8558f0cb94c11d5d1f901900d4a6ea8a8167bd35/src/poetry/utils/env.py#L62-L84 I'd prefer this variant because it does not need to change PYTHONPATH.

If we decide to introduce this feature it will require a test.

I finally had the opportunity to discuss this topic and we are open to this feature. If you are still interested, please consider the remarks from my previous post.

It might make sense to split this in two PRs or at least two commits:

• fixing wheel tag determination
• introducing wheel-tag-regex

I can't come up with a sensible test for the first one because it's only a downstream issue (in poetry), but I'd like to have a test for the second one. Probably, it makes most sense to add a dedicated test for the tag property in test_wheel.py and requires mocking Wheel.get_tags().

@jrandall Any news on this? I'd love to see your fixes being merged in main.

@radoering I believe this can now be closed?

I'll close this one since part of it has already been merged via #591 (the relevant part as per the PR title) and the other part is followed up in #592.