Why overshadowing?!! This does not help debugging

[alkuzad]

There is a bug in the connection.py from urllib3.future but my traceback points to lib/python3.12/site-packages/urllib3/connection.py

I spent like hours confused before seeing urllib3_future folder and figuring out that it OVERWROTE THE URLLIB3 PACKAGE because some other package in the chain used niquests. The package was for some not-super-usefull feature but blocking the main program because boto3 and botocore rely on STABLE URLLIB3.

It is malware-like behaviour that took me hours to debu.

One line fix later and my program works again but it would if you didn't overwrote working library.

I am not telling you where the bug is until you stop this practice and I am officially making request to PYPA to remove it from pypi,

[Ousret]

If you spent half the time you wrote this vague complaint reading PyPI terms or previous issues, you would not be as frustrated as you are right now.

We understand the frustration, but it is what it is. Do what you think is right, we will do the same.

As for your personal knowledge, urllib3 did break boto ecosystem partially or completely not so long ago.

Finally, you said to have spent "hours" debugging this, we're sorry for that,
but this is not a strong incentive for us to wait until the last proton to decay to leverage http2 and http3 with the whole Python ecosystem.... not having a thousand tcp connections open when four would have been sufficient.

regards,

p.s. if you give the reproducer, it would be fixed. but I have a hint that it is already fixed and that you have a old version.

[alkuzad]

It is newest version, I checked main. I will give you a hint, it is missing str() or to_str() whichever is really better idk.

It is fine to progress and to make a new library but breaking decade old solutions because of that is not OK. No one will use urllib3.future by itself, they will use niquests, the same as no one is using urllib3 directly but everyone uses requests. Stars count proves that. Low-level libraries are to create high-level clients that programmers love to use, unless someone has specific need to tinker with very base of the how HTTP requests are done.

I get it, you got frustrated on inability to change the upstream so you want to shake the world to align to what you believe is better. But it is not constructive, the argument that it is easier to upgrade is pointless as it is super easy to create a stub package for people who really can't do one-line code change and leave normal package for people who do.

[alkuzad]

I highly recommend to anyone that finds this issue difficult to work with to mark both niquests and urllib3.future as constraint in pip config:

pip config set global.constraint "https://raw.githubusercontent.com/alkuzad/python-global-constraints/master/stop-overshadowing.txt"

or in ~/.bashrc or ~/.zshrc:

export PIP_CONSTRAINT="https://raw.githubusercontent.com/alkuzad/python-global-constraints/master/stop-overshadowing.txt"

This way installation of both packages will be restricted by constraint and will show the message:

ERROR: Cannot install niquests because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested niquests
    The user requested (constraint) niquests<0.0.0

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts