[proposal] New resolver configuration#938
[proposal] New resolver configuration#938tiran wants to merge 1 commit intopython-wheel-build:mainfrom
Conversation
tiran
force-pushed
the
proposal-new-resolver-config
branch
3 times, most recently
from
ceb5b48 to
071d46c
Compare
|
@shifa-khan has been looking at one of the other tickets related to similar work. |
|
I have inspect our downstream repo. Most
|
Add design proposal for new resolver configuration. See: python-wheel-build#937 Signed-off-by: Christian Heimes <cheimes@redhat.com>
tiran
force-pushed
the
proposal-new-resolver-config
branch
from
071d46c to
3356160
Compare
| - `resolver_dist.sdist_server_url` is replaced by `index_url` parameter. | ||
| All `pypi-*` profile support a custom index. | ||
| - `git_options.submodules` is not needed. Like pip, Fromager will always | ||
| clone all submodules. |
There was a problem hiding this comment.
In our downstream, we have packages that explicitly need submodules=False and cases where submodules point to private repos or have broken URLs. These packages when migrated to YAML would deviate from current behavior. Do we have a workaround to address such cases?
For example, adding an optional submodules parameter with true as the default?
There was a problem hiding this comment.
I'm curious, which package fails to build when submodules are enabled? Do you know? I was under the impression that engineers added submodules=False when the package did not need submodules.
Yes, we have a workaround: keep the Python plugin.
If we really need a submodules: false flag for several packages, then we could consider the feature in the future. I would like to start with a simple configuration (80/20 rules).
| return None | ||
| return pep440_matcher | ||
| ``` | ||
|
|
There was a problem hiding this comment.
We also have simple regex patterns in downstream (e.g., ^v(\d+.\d+.\d+)-stable$). Could we support inline tag-pattern as an alternative to matcher_factory? This would avoid needing a plugin for a simple regex.
There was a problem hiding this comment.
We could add a mutually exclusive field. But I'd rather not. My first PoC had both a matcher_factory and tag_pattern option. It did not feel right. Pydantic does not have native support for mutual exclusive fields. They are also harder to document and explain.
Alternative proposal: Fromager could provide additional matcher factories. ^v(\d+.\d+.\d+)-stable$ is a generic and somewhat common pattern. That would eliminate the need for custom code in downstream.
|
downstream has few plugins call |
tiran
left a comment
tiran
left a comment
There was a problem hiding this comment.
downstream has few plugins call ensure_pkg_info() in prepare_source as boilerplate. Git clones never have PKG-INFO, but build tools (like setuptools-scm) need it before building. Could the git-based providers (gitlab-git, github-git, pypi-git) handle this automatically?
Great point! Yes, this will be handled automatically in two ways:
- Fromager already adds
PKG-INFOto the final sdist. In some cases, the file is added too late for some PEP 517 hooks. - Fromager will add a
.git_archival.txtfile to clones. Lala is working on the feature in #961 / #962 . This works for all setuptools-scm cases.
I'll update the design with the PKG-INFO and .git_archival.txt details.
| - `resolver_dist.sdist_server_url` is replaced by `index_url` parameter. | ||
| All `pypi-*` profile support a custom index. | ||
| - `git_options.submodules` is not needed. Like pip, Fromager will always | ||
| clone all submodules. |
There was a problem hiding this comment.
I'm curious, which package fails to build when submodules are enabled? Do you know? I was under the impression that engineers added submodules=False when the package did not need submodules.
Yes, we have a workaround: keep the Python plugin.
If we really need a submodules: false flag for several packages, then we could consider the feature in the future. I would like to start with a simple configuration (80/20 rules).
| return None | ||
| return pep440_matcher | ||
| ``` | ||
|
|
There was a problem hiding this comment.
We could add a mutually exclusive field. But I'd rather not. My first PoC had both a matcher_factory and tag_pattern option. It did not feel right. Pydantic does not have native support for mutual exclusive fields. They are also harder to document and explain.
Alternative proposal: Fromager could provide additional matcher factories. ^v(\d+.\d+.\d+)-stable$ is a generic and somewhat common pattern. That would eliminate the need for custom code in downstream.
3 participants
Add design proposal for new resolver configuration.
See: #937