ansible / ansible-lint

ansible-lint checks playbooks for practices and behavior that could potentially be improved and can fix some of the most common ones for you
https://ansible.readthedocs.io/projects/lint/
GNU General Public License v3.0
3.5k stars 663 forks source link

Can't install a recent version of ansible-lint with uv #4348

Closed bolinocroustibat closed 6 days ago

bolinocroustibat commented 1 month ago

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 in pyproject.toml (for example >=24.9.2), but in that case I get the following dependency tree solving error:

  × No solution found when resolving dependencies for split (python_full_version == '3.11.*'):
  ╰─▶ Because will-not-work-on-windows-try-from-wsl-instead{platform_system == 'Windows'}==0.1.0 was yanked (reason: This package should not have
      anything published) and only will-not-work-on-windows-try-from-wsl-instead{platform_system == 'Windows'}==0.1.0 is available, we can conclude that
      all versions of will-not-work-on-windows-try-from-wsl-instead{platform_system == 'Windows'} are incompatible.
      And because ansible-lint==24.9.2 depends on will-not-work-on-windows-try-from-wsl-instead{platform_system == 'Windows'} and only
      ansible-lint<=24.9.2 is available, we can conclude that ansible-lint>=24.9.2 cannot be used.
      And because dotfiles:dev depends on ansible-lint>=24.9.2 and your project depends on dotfiles:dev, we can conclude that your project's requirements
      are unsatisfiable.

I also tried the following in the pyproject.toml:

dependencies = [
    "ansible>=10.4.0",
    "ansible-lint>=24.9.2 ; sys_platform != 'Windows'",
]

...but this platform flag seems to have no effect and I get the same error.

  × No solution found when resolving dependencies for split (python_full_version == '3.11.*'):
  ╰─▶ Because will-not-work-on-windows-try-from-wsl-instead{platform_system == 'Windows'}==0.1.0 was yanked (reason: This package should not have
      anything published) and only will-not-work-on-windows-try-from-wsl-instead{platform_system == 'Windows'}==0.1.0 is available, we can conclude that
      all versions of will-not-work-on-windows-try-from-wsl-instead{platform_system == 'Windows'} are incompatible.
      And because ansible-lint{sys_platform != 'win32'}==24.9.2 depends on will-not-work-on-windows-try-from-wsl-instead{platform_system == 'Windows'}
      and only ansible-lint{sys_platform != 'win32'}<=24.9.2 is available, we can conclude that ansible-lint{sys_platform != 'win32'}>=24.9.2 is
      incompatible.
      And because dotfiles:dev depends on ansible-lint{sys_platform != 'win32'}>=24.9.2 and your project depends on dotfiles:dev, we can conclude that
      your project's requirements are unsatisfiable.
bolinocroustibat commented 1 month 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.

davedittrich commented 2 weeks ago

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.

dpprdan commented 2 weeks ago

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.

dpprdan commented 1 week ago

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.

ssbarnea commented 6 days ago

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.

dpprdan commented 6 days ago

@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"

bryanwweber commented 3 days ago

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.