-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Fix indirect dependency on the package six. #6580
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
Comments
Ah, I think I found the issue. In the step where we create the virtualenv, we print I installed both of these versions in a clean environment and validated that v2.22.0 had a dependency on the |
See issue tensorflow#6580 for more details.
See issue tensorflow#6580 for more details.
See issue #6580 for more details.
On Sep 12, 2023, our nightly release workflow (in GH Actions) started failing, with the following error:
Apparently,
six
is a dependency for two of our "vendored" packages, but we didn't have it as an explicit dependency. It's unclear why it was not an issue up until now. My current hypothesis is that this was included by default by either pip or virtualenv, or it was installed because it was a dependency of some other dependency we do have explicitly, and just recently that stopped being true, but nothing in our setup has changed recently, and the package versions used also seem to be the same for the latest successful run, so I haven't been able to validate or understand how this could be the case.Both the latest successful run and the first failed one seem to have the same package versions for the
pip
andvirtualenv
packages, and even thesix
package seems to be initially installed with the same version, but somehow the "test pip package" step, which runs our test_pip_package.sh script, which in turn creates a virtualenv, started failing with thisNo module named 'six'
error.Since this is a dependency of our vendored packages [1, 2], perhaps we should include it as another vendored package, but I'm not quite sure of what this entails. At the same time, I don't know if we should make it an explicit dependency of our product in the requirements.txt, so for now, I lean towards adding it to our requirements_dev.txt file.
The text was updated successfully, but these errors were encountered: