Update PEP 517 to use pyproject.toml from PEP 518 #51
Conversation
PEP 518 gave a detailed rationale for using a TOML config file; I'm pretty sure that's meant to be instead of, not in addition to, the JSON file proposed in this and PEP 516.
|
Hello, and thanks for your contribution! Unfortunately we couldn't find an account corresponding to your GitHub username at bugs.python.org (b.p.o). If you don't already have an account at b.p.o, please create one and make sure to add your GitHub username. If you do already have an account at b.p.o then please go there and under "Your Details" add your GitHub username. And in case you haven't already, please make sure to sign the PSF contributor agreement (CLA); we can't legally look at your contribution until you have signed the CLA. Once you have done everything that's needed, please reply here and someone will verify everything is in order. |
|
I'm also |
|
Is this change OK w/ you, @njsmith ? |
|
Pinging @njsmith again now that Scipy is over. |
brettcannon
changed the title
|
I also emailed Nathaniel directly last week about this and I still haven't heard back. I hope he's okay. |
|
I pinged a mutual friend - apparently Nathaniel has been ill, but it sounded like he should be back soon. |
|
Subscribing.
Haven't seen or heard from him in a while, last time he was warning he would likely be under the weather until at least this week, and it will likely take him some time to get back on track. I'll gently nudge him when I see him. Otherwise the changes made by @takluyver seem to correspond to the discussion I had with Nathaniel. |
|
We are now past the 60 day mark on this PR. Should we just close this and move it to a personal fork to wait out @njsmith ? |
|
Could we instead look at reviewing/merging the change without Nathaniel? I'm very grateful for the work he's already done on this PEP, but one person being ill shouldn't stop the entire process. This shouldn't be a controversial change: between writing this PEP and separating out the more focussed PEP 518, the format and name of the metadata file changed. Since PEP 518 has been accepted and people are already using pyproject.toml (e.g. @dholth's enscons), it seems pretty clear that this proposal should now use that file. |
|
@ncoghlan do you have any issues accepting the proposed changes in Nathaniel's place as BDFL delegate? |
I agree that we can for now behave as if Nathaniel will not be back soon, we haven't seen him for a while here, I just inquired and HR will try to recontact him and let me know what they can tell me. I'm pretty sure he will be happy to have one less thing on his plate. |
Carreau
left a comment
Carreau
left a comment
There was a problem hiding this comment.
2 Minor typos.
One question, should we be explicit as to whether the build dependencies are expected to not be uninstalled if they were not present before trying to build ?
I'm asking that because we could see 2 way of doing this: building in a separate/clean python env (that can potentially be reused, but does not affect user-space); or build using the user env.
pep-0517.txt
Outdated
| agree this is a good idea? | ||
|
|
||
| * We call our config file ``pypackage.json`` instead of | ||
| * We call our config file ``ppyproject.toml`` instead of |
There was a problem hiding this comment.
With PEP 518 accepted, we can assume this particular difference between the two PEPs will go away (and that's also assuming @rbtcollins decides to continue with PEP 516 - he's changed jobs since he wrote that, and may no longer have the time or inclination to champion it as a competing proposal)
pep-0517.txt
Outdated
| sdists to new-style sdists. (E.g., this is one motivation for | ||
| supporting dynamic build requirements.) The ideal would be that there | ||
| would be a single static pypackage.json that could be dropped into any | ||
| would be a single static pyproject.toml that could be dropped into any |
|
With @njsmith not being well, I think it makes sense for @takluyver to add himself as a co-author to get this PEP moving forward again in the meantime. |
|
I've made the various changes suggested - thanks.
Hang on while I count the negatives ;-)
The PEP strongly recommends, but does not require, that build frontends (like pip) run all builds in isolated environments. Building in the user env is probably going to be something 'quick and dirty' tools do, so I think it's OK to leave that behaviour largely unspecified. |
ncoghlan
changed the title
|
@takluyver I interpreted your last comment as overriding the Aside from another round of discussion on distutils-sig, I think the main missing piece now would be a reference implementation. |
|
Thanks @ncoghlan, I hadn't noticed that WIP was in the title. I'll try to make a reference implementation in flit. |
…g/hashing-algos Specify cryptographic hashing algos
7 participants
PEP 518 gave a detailed rationale for using a TOML config file; I'm pretty sure that's meant to be instead of, not in addition to, the JSON file proposed in this and PEP 516.
Ping @njsmith @rbtcollins