Metadata transformation for the build backend#7781
Conversation
de23e93 to
0f110f6
Compare
| } | ||
|
|
||
| /// Allow dispatching between writing to a directory, writing to zip and writing to a `.tar.gz`. | ||
| trait AsyncDirectoryWrite: Sized { |
There was a problem hiding this comment.
This trait will gain a method to add files
| // TODO(konsti): Editables use stored. | ||
| Compression::Deflate, | ||
| ) | ||
| // https://github.com/Majored/rs-async-zip/issues/150 |
There was a problem hiding this comment.
I've been considering making the build backend sync to switch to the sync zip crate
There was a problem hiding this comment.
My intuition would be for the build backend to be synchronous. Unless you see some usefulness out of asynchronous control flow, async will likely just be additional complexity (and worse performance).
The other factor is, how will uv be interfacing with the build backend? If uv needs to call out to the build backend from an asynchronous context, we incur a spawn_blocking call if the build backend is synchronous. On the other hand, if the build backend is always spawned as a separate process, then async doesn't provide any benefit.
0f110f6 to
5f53194
Compare
bae43c2 to
5c7d62a
Compare
BurntSushi
left a comment
There was a problem hiding this comment.
This all looks like a reasonable start to me.
For async, I would bias toward not doing it. @ibraheemdev might have some thoughts here. My understanding is that a build backend is mostly CPU bound anyway, so using async for it might not make a ton of sense?
| use std::io; | ||
| use std::path::{Path, PathBuf}; | ||
| use thiserror::Error; | ||
| use uv_distribution_filename::WheelFilename; |
There was a problem hiding this comment.
I usually like to write imports in three distinct groups, separated by a line break: std imports, non-crate imports, crate imports. (I mention this because this is greenfield code and maybe we can start with this convention. :P)
| /// should update the shared schema instead. | ||
| #[derive(Deserialize, Debug, Clone)] | ||
| #[serde(rename_all = "kebab-case")] | ||
| struct Project { |
There was a problem hiding this comment.
Maybe a dumb question (and this is for my own edification probably because I trust you're doing the right thing here), but do we have code somewhere else for parsing pyproject.toml? Why can't we use that here?
(Putting an answer to that question in the comments might be useful.)
| } | ||
| } | ||
| Ok(Pattern::new(glob)?) | ||
| } |
There was a problem hiding this comment.
How does one write a glob that matches ] and only ]?
(I ask this because I notice there is no handling of escaping here. You can escape most things via brackets, e.g., [*], but I don't think ] can be matched literally here?)
There was a problem hiding this comment.
I don't think you can - If you consider this a concern, best add it to the discourse thread
There was a problem hiding this comment.
5c7d62a to
7797ea9
Compare
Following the discussion at #7781 (comment), it makes more sense to keep the build backend sync.
Following the discussion at #7781 (comment), it makes more sense to keep the build backend sync.
Implement the validation and transformation from
pyproject.tomltoMETADATAandentry_points.txt. There is some incomplete plumbing code incrates/uv-build-backend/src/lib.rsto actually writeMETADATAandentry_points.txtinto a stub wheel or dist-info directory, the logic lives incrates/uv-build-backend/src/metadata.rs.The code is a translation of the relevant specs:
The code is a translation of these with some contextual knowledge. While there are tests, we will only have real coverage once we do the entire wheel writing process and can use them with other tools.
The feature is still hidden. Reference docs for
pyproject.tomlare in the next branch, to avoid publishing them.