It's not possible to install ansible-lint 6.9.0 using poetry

[KamilaBorowska]

Summary

Installing ansible-lint using poetry add ansible-lint@latest is not possible.

Issue Type

• Bug Report

STEPS TO REPRODUCE

Create a new project with poetry init and then run poetry add ansible-lint@latest

Desired Behavior

ansible-lint should be installed.

Actual Behavior

$ poetry add ansible-lint@latest
Using version ^6.9.0 for ansible-lint

Updating dependencies
Resolving dependencies... (0.1s)

Because no versions of ansible-lint match >6.9.0,<7.0.0
 and ansible-lint (6.9.0) depends on will-not-work-on-windows-try-from-wsl-instead (*), ansible-lint (>=6.9.0,<7.0.0) requires will-not-work-on-windows-try-from-wsl-instead (*).
So, because no versions of will-not-work-on-windows-try-from-wsl-instead match *
 and project depends on ansible-lint (>=6.9.0,<7.0.0), version solving failed.

[ssbarnea]

Sorry but this is a bug belonging poetry, not ansible-lint. Our dependencies are declared like this on purpose.

See https://github.com/ansible/ansible-lint/blob/main/setup.cfg#L74

PS. You might want to see why others dislike poetry

[huyz]

Heheh linking to a video dissing Poetry's build-breaking decision (with a weird brownout hack) in order to justify breaking the Poetry installation of ansible-lint on non-Windows machines (with a weird non-existing dependency hack) is quite something. Food for thought...

[blthayer]

Linking to a video about someone's opinion about a tool on a technical thread such as this personally strikes me as unprofessional and juvenile, especially in the context of defending a bizarre hack of pointing to a non-existent package and then claiming "the spec doesn't say packages have to exist!" Very interesting take which surely doesn't violate the principle of least surprise...

It seems to me like the right approach is to document that ansible-lint does not work on Windows (which has been done, excellent!), specify POSIX-only in the trove classifiers (also has been done, great work!). If you're still concerned about Windows users filling up your GitHub issues with "can't install on Windows" type issues, either use a bot to auto-close with a link to the docs or just add something to the top-level __init__.py file to fail on Windows:

import platform

if platform.system() == "Windows":
    raise RuntimeError("ansible-lint is not supported on Windows, see the docs.")

^ surely this import and conditional won't spoil the performance of ansible-lint for POSIX users.

[gtirloni]

Linking to a video about someone's opinion about a tool on a technical thread such as this personally strikes me as unprofessional and juvenile

Sadly par for the course here.

But the funny thing is that the video is full of "incorrect! well, not really, but..", "a huge problem! well, not really, but...", "it's broken! well, not really, but..." ... basically someone doesn't like how something else is for personal reasons, calls it "technical reasons," and it's linked here as a reason for ansible-lint being broken on non-Windows machines with a pretty popular installer (which must be 90% of the userbase -- Linux, that is).

I think your proposal is quite good and to the point, it warns the user about a situation that ansible-lint is not going to support without diverting too many people to someone's crusade against Poetry.

[finswimmer]

Hello @ssbarnea,

unfortunately defining a non-existing dependency for a specific platform is problematic in multiple cases:

• Any tool that is doing a universal locking like Poetry or PDM will raise an error because it cannot find this dependency. Universal locking means, that the dependency resolution is done independently of the current platform and Python version, by only looking at the constraints. Thus the lock file can be used with any Python version that the project aims to be compatible.
• Someone can register this non-existing dependency and suddenly this is pulled into the environment. That's a potential security issue.

The hint in the documentation about the fact, that ansible-lint cannot be installed on Windows, should be sufficient. Maybe put it into the README of this repo as well?

Best regards,
fin swimmer

[KamilaBorowska]

For reference to anyone who finds this ticket, this issue can be workarounded by using markers:

ansible-lint = { version = "^6.9.0", markers = "platform_system != 'Windows'" }

[ssbarnea]

@finswimmer pip-tools compile does not suffer from the same limitations, we use it without problems. You cannot expect that all the dependencies to be always available and I am sure that there are other packages on pypi with similar issues.

I also doubt poetry looks at trove metadata lists only POSIX and not Windows as a supported platform. That is a poetry implementation bug that it fails to evaluate the condition before starts looking for the dependency. I supposed it would also fail if the marker is True is False.

@xfix Thanks for providing a workaround. Feel free to make a PR to add a section for poetry in installation section, so others might find your valuable workaround.

[KamilaBorowska]

My personal opinion is that ansible-lint abuses the requirements system, and this work-around is non-ideal because it would break if ansible-lint were to add a similar hack for some other platform.

[gtirloni]

@xfix thanks for the workaround. I hope ansible-lint re-thinks this.

[netopsengineer]

Agree that Poetry is widely used, and I usually keep even my Ansible environments managed by Poetry, so not having ansible-lint work with it is a bummer. @ssbarnea @ganeshrn is there no other option here?

[la-magra]

Following the setup tools specific configuration in the guide.

And doing the two following changes:

diff --git a/.config/requirements.in b/.config/requirements.in
index 94585501..5e3b3150 100644
--- a/.config/requirements.in
+++ b/.config/requirements.in
@@ -1,5 +1,4 @@
 # Special order section for helping pip:
-will-not-work-on-windows-try-from-wsl-instead; platform_system=='Windows'
 ansible-core>=2.12.0,<2.14.0; python_version<'3.9' # GPLv3
 ansible-core>=2.12.0; python_version>='3.9' # GPLv3
 ansible-compat>=2.2.7 # GPLv3
diff --git a/pyproject.toml b/pyproject.toml
index 7e250c2f..41edf4a3 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -210,3 +210,8 @@ dependencies = { file = [".config/requirements.in"] }
 [tool.setuptools_scm]
 local_scheme = "no-local-version"
 write_to = "src/ansiblelint/_version.py"
+
+[tool.setuptools]
+platforms = [
+  "posix",
+]

Allows the install to proceed in a modern dependency management tool like pdm

pdm add -e file:///home/****/ansible-lint --dev

or adding it manually

[tool.pdm]
[tool.pdm.dev-dependencies]
dev = [
    # "ansible-lint>=6.0.0",
    "-e file:///home/****/ansible-lint#egg=ansible-lint",
]

and doing

$ pdm update
🔒 Lock successful
Changes are written to pdm.lock.
Synchronizing working set with lock file: 0 to add, 2 to update, 0 to remove

  ✔ Update ansible-lint 6.10.3.dev0 -> 6.10.3.dev0 successful
...

seems to work.

The only question is if pip, poetry and pdm (and pip-tools, and pipenv) on windows sends an error message on install or update.
(If someone could test that would be great)

[KamilaBorowska]

I am amazed none of those involved bothered to create an issue with poetry and link it to this thread, nobody. Is everyone afraid of opening an issue with poetry? -- I will not open it myself because I am not an user, so not really suitable to engage with its maintainers.

poetry already has an issue (python-poetry/poetry#7112) which was closed as its developers believe that it's a problem with ansible-lint and there is a working workaround for the issue.

[davidmehren]

@ssbarnea It might be best if you discuss this issue directly with the poetry maintainers, as in the current situation both projects point to the other for being at fault. I don't think we as users can really do something to move this issue forward.

Unfortunately, I'm not deep enough into python packaging to decide if poetry should support the feature that ansible-lint uses or if ansible-lint should not use a fake dependency to make installing on Windows impossible.

[la-magra]

Well, I bit the bullet and tested it on a windows VM.

Unfortunately

+[tool.setuptools]
+platforms = [
+  "posix",
+]

seems to be for show, nothing stops pdm or poetry from installing ansible-lint on windows with that change.

And for the record a bug report was opened for pdm too, pdm-project/pdm#1575

[ssbarnea]

Neither pip, which covers like >99% of package installations from sdist or wheels and that is why we made use of a native feature of it, conditional dependencies. It is bit of hack but it is within the specification as nobody ever documented that all dependencies listed by a package must exist, including optional or conditional ones.

[la-magra]

For those on pdm, a new version was released with the following workaround:

[tool.pdm.resolution.overrides]
will-not-work-on-windows-try-from-wsl-instead = "0.1.0"

[mbwhite]

I find it slightly amusing that the error still occurs when on wsl2. But I'm in agreement with the idea that this is a bit of an abuse of the dependency system.

I find that installing ansible itself with poetry does work - as the required files in 'bin' such as ansible-playbook aren't there.

[kftsehk]

I came across using pdm
This can be workaround

• if you use more recent version of pdm
• manually write dependencies into pyproject.toml
• explicitly drop cross-platform support during pdm lock.

dependencies = [
    "ansible-lint>=24.2.0",  # manually added
]

then use

pdm lock --strategy no_cross_platform

ref: https://pdm-project.org/latest/usage/dependency/#cross-platform