Not breaking Click so much #3138
Replies: 4 comments 8 replies
-
|
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:
Cost of being throughout for the month of October: $4,565.19
I'm just lucky that GitHub is offering 100% discount (so far):
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions