Skip to content
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

Ignore group completely when resolving depencencies. #11104

Open
fizcris opened this issue Jan 30, 2025 · 6 comments
Open

Ignore group completely when resolving depencencies. #11104

fizcris opened this issue Jan 30, 2025 · 6 comments
Labels
enhancement New feature or improvement to existing functionality

Comments

@fizcris
Copy link

fizcris commented Jan 30, 2025

Summary

If we have a project.toml like:

[project]
name = "example"
version = "1.0.0"
description = "desccription"
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
    "matplotlib>=3.10.0",
    "pandas>=2.2.3",
]

[dependency-groups]
internal = [
    "my-app-1">=1.0.0",
    "my-app-2">=2.0.0",
]

[tool.uv.sources]
my-app-1 = { index = "internalRepo"}
my-app-2 = { index = "internalRepo2"}

[[tool.uv.index]]
name = "internalRepo"
url = "https://my-internal-repo.com/simple"
explicit = true

[[tool.uv.index]]
name = "internalRepo2"
url = "https://my-internal-repo2.com/simple"
explicit = true

If in the moment we are solving dependencies there is access to the private repositories it will fail and there is no way to exclude the internal group.

So the following command will fail uv sync --no-group internal. And there is no known way to completely exclude the internal group from dep resolution.

Example

No response

@fizcris fizcris added the enhancement New feature or improvement to existing functionality label Jan 30, 2025
@zanieb
Copy link
Member

zanieb commented Jan 30, 2025

No, there's no way to exclude a group from the resolution at this time. If you did, it wouldn't be installable. What's the use-case for not having access to the index?

@fizcris
Copy link
Author

fizcris commented Jan 30, 2025

That is ok if it is not installable.

If the index is a private repository and the app can only be installed when there is access to that repository, hence if you only need that library for some parts of the code you would have to install them manually when required.

The app could partially work without those libraries when it does not have access but is not able to resolve the deps hence renders the uv unusable and needs manual installation of the libraries.

@zanieb
Copy link
Member

zanieb commented Jan 30, 2025

hence if you only need that library for some parts of the code you would have to install them manually when required.

How would you install these?

Why include them in [dependency-groups] if they can't actually be installed?

Why not generate the lockfile with access to the private index? You can still do partial installs later without access to the index.

@T-256
Copy link
Contributor

T-256 commented Jan 30, 2025

Same as #10201.

I'm thinking of two possible solutions for this (if we want to support such situations...):

First, similar to #11064 but, instead, destruct uv.lock into per-group files (e.g. internal.uv.lock).

Second, it could lazy solving dependency for specified indexes:

[tool.uv.sources]
my-app-1 = { index = "internalRepo"}

[[tool.uv.index]]
name = "internalRepo"
url = "https://my-internal-repo.com/simple"
explicit = true
lazy = true

I don't know how much this is possible, via this option, dependencies with lazy indexes are not resolved in lockfile but when actually requested for install (e.g. uv sync --group internal).

@fizcris
Copy link
Author

fizcris commented Jan 30, 2025

Well image that you have private machines and public machines, you dont want to be maintaining multiple lockfiles.

@zanieb
Copy link
Member

zanieb commented Jan 31, 2025

I don't understand why you'd need multiple lockfiles. You'd lock on the private machine and it'd be usable everywhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement to existing functionality
Projects
None yet
Development

No branches or pull requests

3 participants