Solving dependency with uv on windows not work because of sh

[zhavir]

Somehow, I'm unable to sync my uv lock on Windows when this library is included as a dependency. The issue seems to be that it depends on the sh library, which isn't compatible with Windows. However, sh isn't listed in the pyproject.toml. Do you know if it's currently being used?

That said, when I run it as a pre-commit hook, it works like a charm. I mainly need it because I've written some plugins on top of it, and having type hinting support is really helpful.

[powercoconola]

Can confirm, here's my output:

> uv add gitlint --dev
  × Failed to build `sh==1.14.3`
  ├─▶ The build backend returned an error
  ╰─▶ Call to `setuptools.build_meta:__legacy__.build_wheel` failed (exit code: 1)

      [stderr]
      Traceback (most recent call last):
        File "<string>", line 14, in <module>
        File "C:\Users\username\AppData\Local\uv\cache\builds-v0\.tmpFmoVOk\Lib\site-packages\setuptools\build_meta.py", line
      333, in get_requires_for_build_wheel
          return self._get_build_requires(config_settings, requirements=[])
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\username\AppData\Local\uv\cache\builds-v0\.tmpFmoVOk\Lib\site-packages\setuptools\build_meta.py", line
      301, in _get_build_requires
          self.run_setup()
        File "C:\Users\username\AppData\Local\uv\cache\builds-v0\.tmpFmoVOk\Lib\site-packages\setuptools\build_meta.py", line
      520, in run_setup
          super().run_setup(setup_script=setup_script)
        File "C:\Users\username\AppData\Local\uv\cache\builds-v0\.tmpFmoVOk\Lib\site-packages\setuptools\build_meta.py", line
      317, in run_setup
          exec(code, locals())
        File "<string>", line 5, in <module>
        File
      "C:\Users\username\AppData\Local\uv\cache\sdists-v9\index\dd6dd6a13788cd0f\sh\1.14.3\dg_JFZKLl0-AasHukOu9r\src\sh.py",
      line 37, in <module>
          import fcntl
      ModuleNotFoundError: No module named 'fcntl'

      hint: This error likely indicates that `sh@1.14.3` depends on `fcntl`, but doesn't declare it as a build dependency.
      If `sh` is a first-party package, consider adding `fcntl` to its `build-system.requires`. Otherwise, either add it to
      your `pyproject.toml` under:

      [tool.uv.extra-build-dependencies]
      sh = ["fcntl"]

      or `uv pip install fcntl` into the environment and re-run with `--no-build-isolation`.
  help: If you want to add the package regardless of the failed resolution, provide the `--frozen` flag to skip locking
        and syncing.

I believe this is because the sh package uses fcntl which is Linux-only — gitlint pulls it in as a dependency but it can't build on Windows.

[zhavir]

Yes, exactly! That is the issue

[alelom]

Any progress on this? Gitlint is effectively not compatible with Windows because of this.

---

when I run it as a pre-commit hook, it works like a charm

@zhavir How do you set this up in an uv-based project then?

[powercoconola]

Any progress on this? Gitlint is effectively not compatible with Windows because of this.

when I run it as a pre-commit hook, it works like a charm

@zhavir How do you set this up in an uv-based project then?

The work-around I currently have for this is using gitlint-core instead of gitlint.

[dependency-groups]
dev = [
    "gitlint-core>=0.19.1",
]

[[repos.hooks]]
id = "gitlint"
name = "gitlint"
language = "system"
entry = "uv run gitlint"
args = ["--msg-filename"]
stages = ["commit-msg"]
always_run = true

[zhavir]

Any progress on this? Gitlint is effectively not compatible with Windows because of this.

when I run it as a pre-commit hook, it works like a charm

@zhavir How do you set this up in an uv-based project then?

Basically I haven't add it as direct dependency of the project. I have a different file for configuration on the root folder called .gitlint. This is my pre-commit setting:

    hooks:
      - id: gitlint
        name: gitlint
        language: python
        entry: gitlint
        args: [--config=tools/gitlint/.gitlint, --staged, --msg-filename]
        stages: [commit-msg]
        additional_dependencies:
          - gitlint

[webknjaz]

Hey folks, so I'd like to document that this isn't the packaging metadata fault but should be reported to uv. uv does this “universal resolution” thing where it tries to resolve deps not just for the current platform but also for foreign platforms by also looking into the deptree variants that are explicitly incompatible.

The current stable release it looks into by default is gitlint==0.19.1. And it depends on gitlint-core[trusted-deps]==0.19.1: https://inspector.pypi.io/project/gitlint/0.19.1/packages/84/90/8b6a29ddceb51272a054399d4864eefd28083530349f5735e0bb979c5f0f/gitlint-0.19.1-py3-none-any.whl/gitlint-0.19.1.dist-info/METADATA#line.29.

So uv then looks at https://inspector.pypi.io/project/gitlint-core/0.19.1/packages/b0/57/dea471da24ceac6de8c3dc5d37e4ddde57a5c340d6bac90010898734de34/gitlint_core-0.19.1-py3-none-any.whl/gitlint_core-0.19.1.dist-info/METADATA#line.36 and sees

Requires-Dist: sh>=1.13.0; sys_platform != 'win32'
Requires-Dist: sh==1.14.3; sys_platform != 'win32' and extra == 'trusted-deps'

Because the trusted-deps extra is required, the dependency is then narrowed down to sh==1.14.3; sys_platform != 'win32'. A normal depresolver would've discarded the entry from the tree when on Windows. Their semantics is documented somwhere @ https://packaging.python.org/en/latest/specifications/dependency-specifiers/#environment-markers.
uv, however, still attempts to resolve two variants of the deptree (one for sys_platform != 'win32' and one for sys_platform == 'win32', and combinations for other subvariants). The one for sys_platform == 'win32' would be fine as it wouldn't hit the sh dependency at all. But being stubborn as it is, uv pretends that it's resolving deps for the sys_platform != 'win32' despite actually running on Windows and not needing that. The pinned version only publishes an sdist, and not wheel: https://inspector.pypi.io/project/sh/1.14.3/. So uv attempts building a wheel where it shouldn't.

FWIW, newer versions of sh come with pre-built wheels and thus wouldn't hit the need to be built in an incompatible environment.

The gitlint PyPI project only exists to point to the deps that are tightly pinned to something tested and known to work. As a workaround, you could instead use gitlint-core which would let weird depresolvers go wild and hopefully resolve something they can stomach.

I also looked into the last pre-release versions published and found that v0.20.0.dev3 is the last one to have that dependency in the metadata: https://inspector.pypi.io/project/gitlint-core/0.20.0.dev3/packages/be/5d/eb3c263688d3fddde6846167cf50741eb6a460b2f9399fad72fc0585e09b/gitlint_core-0.20.0.dev3-py3-none-any.whl/gitlint_core-0.20.0.dev3.dist-info/METADATA#line.36
The following v0.20.0.dev6 doesn't depend on sh https://inspector.pypi.io/project/gitlint-core/0.20.0.dev6/packages/13/2c/ff900a2768ccf9f35ccc758e5c62bf38c06233d6b97667a610fad3ceb590/gitlint_core-0.20.0.dev6-py3-none-any.whl/gitlint_core-0.20.0.dev6.dist-info/METADATA#line.32

So another hack would be pip install 'gitlint >= 0.20.0.dev6' (this auto-allows pre-releases for a specific project if you mention such a thing in the version specifier). It was released on March 28, 2023, which lead me to track the dep removal to #476.

There's nothing else to do for the project, except for maybe cutting a public release with a stable version number.