Consider a build mode that modifies the packaged pyproject.toml
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 76
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Over a year ago, @silv-io made a suggestion I'd like to investigate, which is to add the entrypoints discovered by plux to the distribution by modifying the `pyproject.toml` during the build process.
I think this could potentially solve the requirements described in #31 in a neat way, without requiring manually managed files, while at the same time getting rid of build backend specific complexity (like having to [copy files during the pip build process](https://github.com/localstack/plux/blob/8fa45abdfeee6503e1461d24719dac03cb8cbbcc/plux/build/setuptools.py#L160-L171)). An implementation could look like this:
* introduce a new `entrypoint_build_mode` (something like "pyproject-compile")
* when running `python -m build` in the context of the source tree, we assume that we have a .venv with all runtime dependencies installed, so we can safely discover plugins and generate a list of entrypoints
* we add those entrypoints to the the project's `pyproject.toml`, but not the one in the repo, instead we add it to the file that is copied into the build context by the build backend. typically a build backend will create a new folder with all the relevant files from the project. that one we can augment
* we also overwrite the `entrypoint_build_mode` flag of `[tool.plux]` section to `manual` - this instructs plux to not do any dynamic plugin discovery from there on (like when we create a wheel from a already packaged source distribution)
Basically we're "compiling" a new pyproject.toml from the one in the project + what `plux discover` finds.
Integrations for build backends *may* be brittle, since we probably? will probably still have to rely on internals. Or, you could also modify the final zip files. There are a few options where to hook this functionality. But it seems promising.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the proposed entrypoint_build_mode and the build-backend integration described in the issue, then inspect how `python -m build` creates the packaged source tree and how `plux discover` finds plugins. The work is done when the packaged `pyproject.toml` contains the discovered entrypoints, its `[tool.plux]` mode is `manual`, and the repository's original file remains unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100