Closed arcra closed 1 year ago
Ah, I think I found the issue. In the step where we create the virtualenv, we print pip freeze
to see what packages are installed. In the latest successful run, the google-auth==2.22.0
version is installed, whereas in the failing one, google-auth==2.23.0
is used.
I installed both of these versions in a clean environment and validated that v2.22.0 had a dependency on the six
package, and the newer one does not. So the conclusion is the same, we were relying on an indirect dependency.
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.