`[tool.uv.sources]` can't be used as `[sources]` in `uv.toml`

[johnpyp]

trafficstars

As mentioned in the docs, tool.uv.sources works fine for specifying sources overrides, but it seems that [sources] in uv.toml does not.

Confusingly, using tool.uv.sources and a uv.toml doing other things throws this warning:

warning: Found both a `uv.toml` file and a `[tool.uv]` section in an adjacent `pyproject.toml`. The `[tool.uv]` section will be ignored in favor of the `uv.toml` file.

However, it actually works fine to have it split among the two files.

Let me know if you need more to reproduce, but it should be straightforward as it's just a config file distinction for all forms of [tool.uv.sources].

---

Version: uv 0.3.3 Platform: MacOS / Linux Command: uv sync

[charliermarsh]

Can you share an example of the exact setup you're trying to achieve?

[charliermarsh]

I believe sources need to be in the pyproject.toml alongside the dependencies they annotate.

[johnpyp]

I believe sources need to be in the pyproject.toml alongside the dependencies they annotate.

Yeah totally, this makes sense generally. The two things that are weird are:

1. it seems like sources is uniquely inconsistent with the rest of the tool.uv namespace, in that it doesn't support configuration in uv.toml, whereas basically every other property does.
2. Even if I keep tool.uv.sources in pyproject.toml but put the rest into uv.toml, it still gives that warning.

I'm just using sources for a normal path dependency, nothing special, but I started with using uv.toml as my configuration for index-url and extra-index-url - hence putting sources there too. These index urls are generated on-demand, not statically, so I don't want to put them into source control. Of course, that's another issue because I can't mix pyproject.toml and uv.toml generally, but that was the impotence to start using uv.toml in the first place.

[colinjc]

I also have a use case for this. Internally we have a private registry that contains a number of shadowed package versions for legacy tools, which is causing the resolver to not find the OSS packages with the default index strategy.

We could resolve it by setting the default strategy to unsafe-first-index in the global uv.toml we provide, but it would be more security friendly to include a list of overrides for the effected packages in sources instead. Long term we want to purge all of these shadowed packages, but this would really help our current efforts to adopt uv.

[charliermarsh]

@colinjc -- Can you not put that configuration in a pyproject.toml?

[colinjc]

We can, but each project (dozens) would need to do it. Since our uv.toml is generated and shared automatically to all users to keep their private registry auth in sync, it would let us maintain a single list of dependencies to override.

It's not a huge deal for us, just a nice workaround while we hunt down the legacy projects shadowing dependencies when they really shouldn't be.

[johnpyp]

Echoing Colin's usecase - generated, often not source-controlled config is very common in large environments for things like registry configuration that may not be static.

In other ecosystems, we use git-untracked files like .npmrc, .cargo/config.toml, settings.gradle.

Tools which support multiple of these merged together are the best 🙏

[charliermarsh]

I believe we intentionally don't support this and it will now error (instead of silently ignoring).

[befelix]

I would have another use-case for sources in uv.toml: My laptop doesn't have a GPU, so I generally want any pytorch package to be the cpu-only variant. While we can handle this for our local projects via pyproject.toml, if I install external dependencies directly into a fresh venv I have to manually pass the corresponding index url again. Adding the pytorch cpu-only index (without marking it at explicit) is not an option, since it has unintended side-effects unless we use an unsafe index strategy. Being able to explicitly pin pytorch to the cpu index globally via a sources field in the uv.toml would resolve that issue.

[ipeevski]

Along the lines of what has been said before, this is my use case (that gives the warning anytime I run uv):

I want to specify torch sources/indexes (I don't mind where, preferrably in the uv.toml file, but currently it only allows in project.toml) I want to specify my cache-dir to be on the same drive as my project (so hard links work) I don't want to commit potentially sensitive information about where my cache-dir is and more to the point, it will not be a valid location for most people (as not everyone has a P: drive).

So, currently, I don't see a way to reconcile those two requirements (my wants above)

[charliermarsh]

Why can’t you put the cache-dir setting in a user-level uv.toml?

[ipeevski]

Why can’t you put the cache-dir setting in a user-level uv.toml?

I didn't know that's an option. It looks like that works and doesn't give the warning above, therefore that works for what I needed. Thank you @charliermarsh

[orishamir]

I believe we intentionally don't support this and it will now error (instead of silently ignoring).

May I add, that while having [sources] inside uv.toml of the project indeed yields an error stating sources field is not supported in a uv.toml file, it does not error in the case where [sources] appear in a uv.toml of system-level configuration (in %SYSTEMDRIVE%\ProgramData\uv\uv.toml in windows at least).
So the [sources] inside system-level configuration silently gets ignored. A warning in that case would be helpful since it caused significant headaches

By the way - you are doing an incredible job with UV, I can't thank you enough!

[cylixlee]

My usecase is very close to what @befelix describes.

I'm writing a lib based on PyTorch on my laptop, which does not have GPU, and I configured the [tool.uv.sources] section with an explicit pytorch-cpu index. However, because the [tool.uv.sources] section can only be specified in pyproject.toml, I have to comment out the section every time I publish it to PyPI.

If the [sources] section is allowed in uv.toml, I can easily use pytorch-cpu index locally -- I can add uv.toml to .gitignore and there's no need to comment out those configuration again!

uv is the best package manager I've ever met and I appreciate your work so much, and I can't be too grateful if this feature is accepted😊.

[konstin]

@cylixlee Have you seen https://docs.astral.sh/uv/guides/integration/pytorch/#configuring-accelerators-with-environment-markers? We added this feature specifically for that torch use case.

[cylixlee]

@konstin Yeah, the markers is a good choice, however it may influence downstream: I personally use Windows+PyTorch CPU and Linux+GPU, however the downstream may not want to pair up like that...

I also tried the extras, but writing a lot of optional dependencies for every PyTorch-related lib is not a very pleasant work.😂

[johnpyp]

@konstin For the pytorch specific usecase, I'm in a situation where I'm still eager for developer-specific uv.toml sources, mainly because using extras doesn't work very well for this. Some developers have AMD gpus, some NVIDIA gpus, etc. and we want to be easily accessible for them. As far as I can tell, even if I run uv sync --extras rocm (e.g for an AMD gpu), running uv run ... then tries to sync what it thinks is the default extras set. i.e the developer now has to specifc --extras for every single command they run...

sys_platform markers can't account for this unless I'm mistaken.

(This is a different motivation for this same thing than what I first described last year, just another one running into a similar flexibility issue)

[charliermarsh]

(If you use uv run in lieu of uv sync, it will never remove any installed extras.)

[amitavaghosh2]

Off all this nonsense what i don't understand is, uv add --active ../../commons , does nothing and the solution is to uv pip install -e . Python and its language is a different kind of broken than Java's XML horeshit.

[rkechols]

I'd also like to put a vote in for being able to specify tool.uv.sources config outside of pyproject.toml. My use-case is also pytorch; some developer machines have GPUs, some don't, and it's independent of OS. To me the intuitive solution was to put [[index]] and [sources] entries in my uv.toml file, and I was surprised that the [sources] config was rejected.

Do we have any news whether this is on the roadmap?

[zanieb]

It's not on the roadmap, no. Defining sources outside the pyproject.toml would invalidate the lockfile. We'd rather invest in things like being able to toggle sources based on the presence of a GPU.

[ncoghlan]

I believe I just ran into this restriction trying to enable uv source overrides in venvstacks. That uses uv pip compile and uv pip install from input requirements files, with nary a pyproject.toml in sight.

There isn't any lock file to inadvertently invalidate in that usage model.

[zanieb]

That's fair, but allowing it in that context but not other ones adds a bunch of complexity! If we choose to do so, we'll need to be careful about it.

[ncoghlan]

Would it be viable to add a pip.sources table to constrain the non-project source definitions to just the use cases that aren't using uv.lock? (although that may be the extra complexity you're referring to)

Independently of that question, I'll see if I can rework venvstacks to use pseudo-projects instead of requirements files.

[ncoghlan]

@charliermarsh In relation to https://github.com/astral-sh/uv/issues/6772#issuecomment-2487042845, does "it will now error" refer to attempting to specify [sources] in uv.toml at all, or more specifically to attempting to install a package that has an override specified in uv.toml?

Or is it only when pyproject.toml exists (and has a tools.uv.sources field?), so uv pip compile will never trigger it?

[TheTerrasque]

It's not on the roadmap, no. Defining sources outside the pyproject.toml would invalidate the lockfile. We'd rather invest in things like being able to toggle sources based on the presence of a GPU.

I just came over this problem and I believe this is unwise. The sources settings in relation to pytorch is clearly a system-wide and not project setting. You not only have gpu / cpu, but type of gpu and with nvidia version of cuda installed. Furthermore, as some have pointed out here there's many situations where it's organization wide settings and again not project-scope settings.

[patrontheo]

My usecase is very close to what @befelix describes.

I'm writing a lib based on PyTorch on my laptop, which does not have GPU, and I configured the [tool.uv.sources] section with an explicit pytorch-cpu index. However, because the [tool.uv.sources] section can only be specified in pyproject.toml, I have to comment out the section every time I publish it to PyPI.

If the [sources] section is allowed in uv.toml, I can easily use pytorch-cpu index locally -- I can add uv.toml to .gitignore and there's no need to comment out those configuration again!

uv is the best package manager I've ever met and I appreciate your work so much, and I can't be too grateful if this feature is accepted😊.

I have exactly the same use-case as @cylixlee and was hoping for the same solution (put the sources in uv.toml so that it applies locally only). If not possible in uv.toml, could it be in something like pyproject.dev.toml, that would get merged with the main pyproject when running uv sync ? Or do you see any other solution for that issue ? @zanieb