Closed bolinocroustibat closed 6 days ago
Update:
... in the meantime, I found a way to bypass this issue, by adding the following to the pyproject.toml
:
[tool.uv]
environments = ["platform_system != 'Windows'"]
...but it's a solution using the uv proprietary section.
It would be great if the limitation with Windows was implemented for standard pyproject.toml
files, as "ansible-lint>=24.9.2 ; sys_platform != 'Windows'
is the PEP standard.
This same dependency resolution problem is happening with poetry
on Mac OS X, which is not a Windows platform. It seems the method of trying to enforce operating system compatibility with an Ansible project via a fake dependency meant to be an error message at install time using pip
is problematic for the general case.
Could this please be done instead at runtime in the Python code, with a command line option (and config file setting)? This would allow a developer/debugger to ignore the problem when linting to avoid this being a blocker when debugging other dependency issues.
It would be great if the limitation with Windows was implemented for standard
pyproject.toml
files, as"ansible-lint>=24.9.2 ; sys_platform != 'Windows'
is the PEP standard.
That seems to be a uv
issue.
AFAIU the issue is as follows:
uv
is creating a universal/cross-platform project lockfile, i.e. it is trying to resolve a package (in this case ansible-lint
) for all platforms, so also for Windows. poetry and pdm essentially do the same. Due to #2712 it is not possible to resolve ansible-lint>=6.9.0
on Windows, hence the error.
[tool.uv] environments = ["platform_system != 'Windows'"]
That is uv
's way to restrict the environments against which to resolve dependencies. It is probably a good idea to declare it like this for an ansible project anyway. If "ansible-lint>=24.9.2 ; sys_platform != 'Windows'
were observed by uv
as intended (see the linked issue above), uv
would still build the lockfile for Windows as well, just not with ansible-lint. There might be edge-cases where this is useful, but probably not for an average ansible project.
While I find the use of a fake dependency to prohibit the installation on a certain platform not very elegant, I am also puzzled by the fact that apparently (i.e. AFAIK) python does not provide an obvious solution for this (IMHO) reasonable use-case.
I am going to close is as I am unable to reproduce it with current uv 0.5.1.
In fact we already use uv to test ansible-lint itself (via tox-uv), so I really doubt that is still true.
@ssbarnea You're confusing the uv pip interface¹ with the uv project interface². The pip interface doesn't use uv.lock
files.
Steps to reproduce:
uv init
uv add ansible-lint
uv pip show ansible-lint
Alternatively uv add "ansible-lint>=24.9.2"
will trigger the "No solution found" error.
¹ "Manually managing environments and packages — intended to be used in legacy workflows or cases where the high-level commands do not provide enough control."
² "Creating and working on Python projects, i.e., with a pyproject.toml
"
I am also experiencing the same issue as in the OP. The recommendation from @dpprdan to add
[tool.uv]
environments = ["platform_system != 'Windows'"]
to pyproject.toml
, along with enforcing that ansible-lint >= 6.16
worked for me.
The real problem that I was experiencing was with an incompatibility of ansible-lint
with ansible-compat
from https://github.com/ansible/ansible-lint/issues/3408. uv
was resolving the 6.8
series of ansible-lint
which didn't have the Windows package depedendency.
Please, please consider making this a runtime check. As seen in issues related to poetry and pdm, this is not a unique problem and reports of this will continue to come in I expect.
Environment: MacOS 15.0 Ansible version: 10.4.0 uv version: 0.4.15
When trying to installed ansible-lint n a uv-managed virtual environment, with
uv add ansible-lint
, uv will only installed the version 6.8.7 which seems to be the last version with a dependency tree that uv can resolve. So I tried to force a more recent version by specifying the version inpyproject.toml
(for example>=24.9.2
), but in that case I get the following dependency tree solving error:I also tried the following in the
pyproject.toml
:...but this platform flag seems to have no effect and I get the same error.