-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
virtualenv should lower deps on six to six>=1.9.0 #1605
Comments
Six was never vendored, we just added it. The problem here I think is that generally it's not recommended to install tools in the global namespace, use the zipapp in such cases of use pipx. 🤔Is an option. |
That being said if someone fills in a pr trying to achieve this I'll review it and accept it, but I have no plan to work on this myself. |
Thanks for confirming, I was afraid you might refuse it. Now I can investigate how hard it would be to lower the min version needed. |
A hack, but low hanging solution is to vendor just ensure text and ensure str into our util package 🤷♂️ |
I am already working on this but given the nature of six, and how often is updated I wonder if vendoring the entire file would not be easier. You should see the first POC PR soon. Probably we will need jobs to test min-requirements if we do not already have them. |
I'm personally not a fan of vendoring code; so 🤷♂ prefer to have as little as possible vendored code |
The current removal of six vendoring from virtualenv introduced some serious problems with installation of virtualenv on operating systems that shipped with older versions of six. Examples are CentOS 7/8 and RHEL 7/8.
Upgrading six with pip will break the support-contract. By keeping a more relaxed dependency this can be avoided and people could avoid failures when installing virtualenv on these systems.
Before someone asks why not building a newer six rpm for these, I will try to answer: building the rpm is easy, releasing it is a huge efforts because these OS versions where released long time ago, some are in extended support. This means that some of them will receive only critical backports and not library upgrades, which can break tons of tools using them. I am personally pro upgrading six on these but I mention this because I am realistic about what has chances to happen or not. Even if this will happen it will take months, months where people will hit the notorious ensure_text exception.
The text was updated successfully, but these errors were encountered: