![]() Support calling `prepare_metadata_for_build_wheel`, which can give you the metadata without executing the actual build if the backend supports it. This makes the code a lot uglier since we effectively have a state machine: * Setup: Either venv plus requires (PEP 517) or just a venv (setup.py) * Get metadata (optional step): None (setup.py) or `prepare_metadata_for_build_wheel` and saving that result * Build: `setup.py`, `build_wheel()` or `build_wheel(metadata_directory=metadata_directory)`, but i think i got general flow right. @charliermarsh This is a "barely works but unblocks building on top" implementation, say if you want more polishing (i'll look at this again tomorrow) |
||
---|---|---|
.. | ||
gourgeist | ||
install-wheel-rs | ||
pep440-rs | ||
pep508-rs | ||
platform-host | ||
platform-tags | ||
puffin-build | ||
puffin-cli | ||
puffin-client | ||
puffin-installer | ||
puffin-interpreter | ||
puffin-package | ||
puffin-resolver | ||
puffin-workspace | ||
wheel-filename | ||
README.md |
Crates
pep440-rs
Utilities for interacting with Python version numbers and specifiers.
pep508-rs
Utilities for interacting with PEP 508 dependency specifiers.
platform-host
Functionality for detecting the current platform (operating system, architecture, etc.).
platform-tags
Functionality for parsing and inferring Python platform tags as per PEP 425.
puffin-cli
Command-line interface for the Puffin package manager.
puffin-client
Client for interacting with PyPI-compatible HTTP APIs.
puffin-installer
Functionality for installing Python packages into a virtual environment.
puffin-interpreter
Functionality for detecting and leveraging the current Python interpreter.
puffin-package
Types and functionality for working with Python packages, e.g., parsing wheel files.
puffin-resolver
Functionality for resolving Python packages and their dependencies.
wheel-filename
Functionality for parsing wheel filenames as per PEP 427.