We have discussed this a bit on the pull request and it seems like the main blocker is the “searchability” of the name:
The problem is not what to use for python -m , but that build as a directory name is way too common with established perception.
Personally I would go with a more unique name. python-build is also not a very good name since it is the pyenv command to build a Python installation, and I expect most Google results to point there due to pyenv’s popularity.
But since we are opening the scope and bringing more users, I think it should not be that much of an issue, the name would be more widespread as the userbase grows. I think pip install build is very easy to remember.
If we had a good name to replace it, I would just use it instead, but that is proving difficult. So, I think it is worth to maybe reconsider keeping the name.
We don’t have a clear direction from where to proceed here so things are tricky . I feel myself being pulled from both directions.
As long as you’re happy to extend the scope to support automatically provisioning build dependencies I’m happy with going ahead with build; and accepting the project under PyPa. We can put the current behaviour under a feature flag (e.g. --isolation none, while default would be --isolation pip). I’d be happy to help out with maintainance too if that’s the case.
Another benefit of doing this is that it’ll let us remove the CLI from pep517 (the library) and to start pushing users toward this new tool for the CLI-based use cases.
A gentle nudge to see what the state of this is. IIUC, the --isolation flag was marked as a “blocking” feature request for moving this project into PyPA.
With PEP 609 accepted, we now have a proper process to accept this into PyPA when we want to go down that route.
The --isolation flag (well, actually --no-isolation, isolation is the default behavior now) is implemented in master, I’d like to do a release but there are a few things I want to get in place first. I am not sure whether it makes sense to propose now or after the release, I have been a bit busy so I don’t have a concrete ETA for it, I’d say maybe 1 month? Although, it might have to be a bit longer than that.
I would suggest that you fix the release blockers, ask formally for PyPA project acceptance, (hopefully) get acceptance, and then make the fresh release along with an announcement that it’s now a PyPA project. However, if there is something about PyPA membership that would logistically make it easier for you to fix the release blockers, then please say so and disregard my suggestion.
Hi all, I would appreciate if someone could help maintain/test the project on Windows. I don’t use Windows and I end up spending a lot of time spinning up VMs and fighting the Windows workflows I am not used to , so if anyone could lend a hand it would be really appreciated .
It’s mainly to look at the Windows specific quirks, I would ping you when I need some help debugging issues and to review/test changes that affect Windows. It can be done as best effort, without much commitment, if you want.
You can ping me as well, though hopefully you are able to get CI running first, which will make it easier for part-time helpers to figure out what’s going on in weird situations.
(And thanks for putting the call out for help! There shouldn’t be any shame in doing so, but plenty of people wouldn’t, so good job )
Pursuant to PEP 609, as a PyPA member I’d like to propose that we vote on moving python-build into the PyPA namespace. Anyone willing to second the proposal so that we can go ahead with the vote? @bernatgabor maybe?
Unfortunately before we need to do any voting we need to finish Implementing PEP 609: PyPA Governance, specifically getting the pypa-committers list up-to-date.
I think python-build is going to be an uncontroversial addition here, and considering that apparently pep517 is removing pep517.build in favor of python-build, I’d like to get this sooner rather than later. Do y’all think we should, in the interests of expedience, do one of:
Adopt python-build under the old “no process” process?
Use a modified process where we start a vote on the Packaging discourse and advertise it on the existing pypa-committers and distutils-sig mailing lists?
I suppose it’s not terribly important to move the project right away, but it would at least be nice for @FFY00 to be an official PyPA member (though I suppose that doesn’t matter until membership corresponds to voting rights…), considering all the work he’s put into this and other projects.
. I feel myself being pulled from both directions.
I’d be happy to help out with maintainance too if that’s the case.
, so if anyone could lend a hand it would be really appreciated 
.
)
! All comments here should have been addressed.