Is there a pyproject standard for sources specification of packages?

Packaging Standards
1

Reading astral/uv docs I find:

Sources are only respected by uv. If another tool is used, only the definitions in the standard project tables will be used.

Here is an example:

[project]
dependencies = ["httpx"]

[tool.uv.sources]
httpx = {
  git = "https://github.com/encode/httpx",
  tag = "0.27.2",
  marker = "sys_platform == 'darwin'"
}

Hence, when a user installs my project from say Github with pip they won’t get the right packages (for Darwin.). I need extra instructions for them in that case, or force them to install uv.

Is there a pyproject.toml standard for sources specification that uv isn’t following, or there isn’t one?

Any recommendations of how to specify those sources (I’m also using different hardware markers.)?

2

Short story - there isn’t one.

This is an area where we believe tools are best to innovate, rather than being constrained to one fixed idea. If they all seem to be aligning on something similar, and there are real benefits to sharing the specification, it might be considered.

There have been some past discussions about this, though. If you find those (I think they used the term “Repository specification”?), you may find some more context on why this is a harder problem than it may seem.

2 Likes
3

It depends on what you want to accomplish exactly. Some of these are supported by standard dependency specifiers in declarative configuration; others are not (e.g. alternative indices). The specific example you provided might also be expressible as:

[project]
dependencies = [
  "httpx ; sys_platform != 'darwin'",
  "httpx @ git+https://github.com/encode/httpx@0.27.2 ; sys_platform == 'darwin'",
]

Or (not supported by pip yet):

[project]
dependencies = [
  "httpx",
]

[dependency-groups]
dev = [
  "httpx @ git+https://github.com/encode/httpx@0.27.2 ; sys_platform == 'darwin'",
]

Each will require you to make different sacrifices (in order: have users install uv; be unable to publish your package to PyPI; possibly needing to execute multiple commands).

1 Like
4

Some related threads:

[I think there are more such threads, but these were the easiest to find for me, because, obviously, I created them.]

1 Like