Skip to content

Support {root:uri}-like workflow in build-system.requires #990

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
LecrisUT opened this issue Feb 13, 2025 · 2 comments · Fixed by #992
Closed

Support {root:uri}-like workflow in build-system.requires #990

LecrisUT opened this issue Feb 13, 2025 · 2 comments · Fixed by #992

Comments

@LecrisUT
Copy link
Collaborator

Consider a project with multiple sub-packages that depend on each other through their cmake find_package. We want that during the build step with isolation the appropriate dependency is used:

  • when built from sdist: use the PyPI index
  • when built from local git checkout: use relative path pointer
  • when built from git url/archive: same as local checkout (if possible)

Borrowing hatch's {root:uri} the effective pyproject.toml would look like

[build-system]
requires = [ "foo >=1.0 @ {root:uri}/../bar" ]

Afaiu this is not possible because the pip/uv fronted would have to recognise that pattern and it would not be acceptable on PyPI.

But we have dynamically inserted build-system.requires, so wouldn't it be possible to expose that on a tool.scikit-build field and expand it with or without the @ qualifier?

@henryiii
Copy link
Collaborator

Do you have a link to the hatchling feature? We ultimately have to report a valid package specifier that is passed to pip/uv/etc, but I believe with overrides (we already have if.from-sdist) all we'd need is a config option for a package to add to the dynamic requirement list.

@LecrisUT
Copy link
Collaborator Author

Do you have a link to the hatchling feature?

Basically they resolve the paths to file: before handing over to the frontends. And I see that they only support file:, so if we focus only that form also, it should be easy to implement that translation as well.

@LecrisUT LecrisUT linked a pull request Feb 21, 2025 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants