gridfm-graphkit 0.8.0rc1 has unsatisfiable dependency constraints (urllib3 vs gridfm-datakit)

[romeokienzler]

Summary

gridfm-graphkit==0.8.0rc1 declares dependencies that cannot be satisfied together. Every published version of the required gridfm-datakit is incompatible with 0.8.0rc1's urllib3 constraint or with PyPI in general.

Conflict

gridfm-graphkit==0.8.0rc1 requires:

• gridfm-datakit>=1.0.2
• urllib3>=2.6.0

But on PyPI:

• gridfm-datakit 1.0.2 and 1.0.3 pin urllib3<2.0.0 — conflicts with urllib3>=2.6.0.
• gridfm-datakit 1.0.4 depends on gridfm-datakit-winblock; sys_platform == 'win32', which is not published on PyPI, so the version cannot be installed on any platform that performs full resolution.

Result: no version of gridfm-datakit satisfies gridfm-graphkit==0.8.0rc1's own constraints.

Reproduce

Add to a pyproject.toml:

[project]
requires-python = ">=3.12,<3.14"
dependencies = ["gridfm-graphkit==0.8.0rc1"]

Then uv lock (or pip install) fails with:

Because gridfm-datakit>=1.0.2,<=1.0.3 depends on urllib3<2.0.0 ...
Because there are no versions of gridfm-datakit-winblock and gridfm-datakit==1.0.4
  depends on gridfm-datakit-winblock{sys_platform == 'win32'}, we can conclude that
  gridfm-datakit==1.0.4 cannot be used.
And because gridfm-graphkit==0.8.0rc1 depends on gridfm-datakit>=1.0.2 and
  urllib3>=2.6.0, we can conclude that gridfm-graphkit==0.8.0rc1 cannot be used.

Possible fixes

• Publish gridfm-datakit-winblock to PyPI, or remove that dependency from gridfm-datakit 1.0.4, and/or
• Release a gridfm-datakit that allows urllib3>=2.6.0, and/or
• Relax urllib3>=2.6.0 in gridfm-graphkit to a range compatible with an installable gridfm-datakit.

Context

Hit while attempting to bump gridfm-graphkit from 0.0.7 to 0.8.0rc1 in IBM/algorithm-nexus. The previous torch-version conflict that motivated the bump is now resolved — thanks for that — but the package is currently uninstallable due to the above.

[romeokienzler]

Some additional context on the gridfm-datakit-winblock half of the conflict — it was introduced intentionally as a Windows-blocking trick in gridfm/gridfm-datakit@8e53343f ("Enforce Python <= 3.11 on Windows", 2025-12-02, by @albanpuech). The dependency line was changed from:

"python_version < '3.12' ; sys_platform == 'win32'"

to:

"gridfm-datakit-winblock ; sys_platform == 'win32' and python_version >= '3.12'"

The intent was clearly to make pip install fail on Windows + Python ≥3.12 by depending on a non-existent package. The unintended side effect is that any resolver doing universal / cross-platform resolution (e.g. uv lock, Poetry, pip-tools with --universal) fails on every platform, not just Windows — it can't prove the Windows marker is unsatisfiable without finding the package, and the package doesn't exist on PyPI.

Two clean ways to express the same intent without breaking universal resolution:

1. Put the platform restriction in [project] requires-python / Trove classifiers and document Windows + 3.12 as unsupported, or
2. Use the older marker-style form, which resolvers can evaluate without reaching the index:

   "python_version < '3.12' ; sys_platform == 'win32'"
   

   (the previous line — combined with requires-python = ">=3.10,<3.13" it makes Windows + 3.12 effectively uninstallable, but only on Windows).

Either would unblock downstream universal-lock consumers like us. cc @albanpuech.