6.6: broke our config code :(

[ggainey]

The change to BandersnatchConfig in f405f48, released in 6.6, breaks code written for previous versions.

The commit notes "As (mostly) an implementation detail, BandersnatchConfig is changed to be a subclass of ConfigParser. The BandersnatchConfig singleton can be used anywhere a ConfigParser
instance is expected without having to use '.config' to access a nested ConfigParser." (emphasis mine)

It's not "without having to use" - it's "breaks if you do use". That breaks code like ours, here https://github.com/pulp/pulp_python/blob/main/pulp_python/app/tasks/sync.py#L62

There's nothing in the changelog about a breaking change, and our CI hasn't been pulling in 6.6 yet - so the first we knew about this, was when an end-user reported it :(

Since our code runs in a lot of environments that may not be able to pull 6.6, we're going to have to pin to 6.5 until we figure out how to correctly handle the change.

[cooperlees]

Sorry this broke you. I feel we should get some CI that builds periodically with bandersnatch master to find issues like this before we release maybe?

That said, let's come up with something. I happy to make it compatible with 6.6.1 or move to 6.7 with a fix. Let me know how you want to move forward ...

• We can also add a test with how you use it and explain "test config works for pulp" or something as you're a major user

I feel this is all fixable, sorry to cause the pain. Without CI tho, things are going to break. Let's just improve things and move forward.

[ggainey]

Good morning! Don't stress overmuch - it's def fixable. I think a 6.6.1 that allows BandersnatchConfig().config to not-break pre-6.6 code paths would be optimal (but I have not yet had enough coffee to have a patch in mind...)

Our CI runs all the tests nightly. However, it also runs on python-3.9 (because we have some downstream projects that upgrade Very Slowly), and so it's selecting bandersnatch-6.3 (!), and so everything was green. As a result, we didn't find this in our CI either - took one of those downstream-users setting up to "upgrade all our dependencies" to switch to py-3.12, which allowed 6.6 to get selected by pip, aaaand...here we are. The joys of complicated software stacks with transitive dependencies.

Anyway - our downstream user is content to pin to 6.5 for the moment, so we have some time to get a 6.6.1 that unbreaks things. Thanks for the quick response!

[pombredanne]

I feel this is all fixable, sorry to cause the pain. Without CI tho, things are going to break. Let's just improve things and move forward.

@cooperlees this should be easy enough. FWIW, I use this on one of my projects to systematically run with the latest and greatest of every deps on every supported Pythons.
This is OK, BUT this would only work IFF we were to run it daily.
https://github.com/aboutcode-org/scancode-toolkit/blob/e795bc6e1e531a0657b7be2363ec746520a5ae64/azure-pipelines.yml#L218