Not breaking Click so much

[Rowlando13]

It feels like we don't have great visibility into whether a patch is going to break another more important part of Click. @davidism Would you mind if I added Flasks test suite as a non blocking(can still merge with failures) CI? @kdeldycke Any other ideas?

[kdeldycke]

I use my own Click Extra project as the canary in the coal mine. I have tons of hacks, patches and workaround implemented there. And they all compounds.

So I run my test suite against a huge matrix of conditions:

• Click: last released version / stable branch / main branch
• Cloup: last released version / master branch (cc @janluke)
• Python: 3.10 / 3.14 / 3.15
• All platforms: Ubuntu / macOS / Windows
• Architecture: arm64 / x86_64

Cost of being throughout for the month of October: $4,565.19

I'm just lucky that GitHub is offering 100% discount (so far):

[janluke]

Wow! :D

[Rowlando13]

This is awesome! I appreciate the extra coverage from click-extra.

[pombredanne]

FWIW, A common issue I have experienced is API breakage with Click in ScanCode and other of our apps. So much that this broke the build of dotnet, and each time is generating quite a bit of churn. And I am considering vendoring or forking Click entirely to get some controlled stability.

[Rowlando13]

So it looks like ScanCode is an application. So you should be able to pin click, rather than having to vendor it. Is there something I am missing, I see it tries to work on a lot of Linux distros, which I don't know anything about.

[pombredanne]

The thing is that ScanCode:

• is used as an app (provided as a bundle with all included dependencies), or
• is used as a library (installed via pip),
• is used as an app (installed from pip)

The issues come when folks install from pip as an app, as you cannot get both pinned and opened version ranges of course. :).
Using as a library makes you you own integrator and you need the freedom to select which versions you want and therefore we need open ranges there.

So for me, the alternative is likely:

• vendor or fork key libraries that have show to be problematic, so we control exactly the update cycles
• publish multiple variants on PyPI using different names but the exact same codebase, each variant with different pinned/opened version ranges (which would be easy to do with https://github.com/aboutcode-org/flot that supports multiple pyproject.toml for the same source tree), hoping that users will do the right thing and pick the correct variant.

None is exactly a happy thing, but I cannot see another way out.

[ThiefMaster]

I think splitting your package in a library part (scancode, no click dependency) and a CLI part (scancode-cli, with a pinned click dependency) might not be such a bad idea... Unless it's common for people to use both at the same time.

[Rowlando13]

In that case I agree with @ThiefMaster.

[Rowlando13]

So @pombredanne this is exactly what I was concerned about. I think what we are missing is a suite that has a very large click app actually built and has tests for it, which is why I was thinking about adding flask's test suite. Then we can grow our internal suite over time.

[ThiefMaster]

It might be a good idea to not only do it with Flask (good starter though!) but also other applications that use click and have decent test suits covering their CLIs.

And of course at the same time making sure we have test coverage for any of the parts that got accidentally broken (e.g. anything receiving a sentinel object incorrectly which I think was the main issue lately)

[Rowlando13]

I think there is a fairly straightforward albeit manual way to do this:

1. Fork it on my github
2. Patch clicks versions locally in the pyproject.toml like this:

dependencies = [
    "blinker>=1.9.0",
    "click",
    "itsdangerous>=2.2.0",
    "jinja2>=3.1.2",
    "markupsafe>=2.1.1",
    "werkzeug>=3.1.0",
]
[tool.uv.sources]
click = { git = "https://github.com/pallets/click", branch = "stable" }

3. Run the suite with pytest.

I did this for the last release which was fine.

@ThiefMaster Do you have any other good repos in mind?

[kdeldycke]

You don't need to change the pyproject.toml.

Here would be my workflow (inspired by click-extra), to test the dev Flask with arbitrary Click branches:

$ git clone https://github.com/pallets/flask      
$ cd flask
$ uv venv --python 3.14
$ source .venv/bin/activate
$ uv sync --all-extras     
$ uv run --with "git+https://github.com/pallets/click.git@main" -- pytest

[Rowlando13]

Thanks for this! It works great!