The Gazelle Python Manifest hash: how critical is it? Can we add a flag to remove it? #2974
-
|
AIUI, the gazelle python manifest hash line only exists so that What are the thoughts on optionally removing the hash? Eg via something like: gazelle_python_manifest(
name = "gazelle_python_manifest",
modules_mapping = ":modules_map",
experimental_exclude_hash = True, # bleh. Maybe experimental_include_hash = False (default True) is more readable
)Context:Our CI pipeline recently slowed down significantly because we moved to an internal python package index that is having some latency issues. This means that when people run Some days we have a lot of changes to our python dependency versions, and thus a lot of changes to the Of course, this isn't an issue with Our CI is set up to run |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
We're still locking our requirements outside of Bazel (eg directly with So the hash is effectively taking place of the bazel action cache for generating the lock file, got it. |
Beta Was this translation helpful? Give feedback.
-
|
If you specify the requirements file, then it will use the hash to short-circuit the However, if you don't specify it, then it will use the bazel action cache to see if the test needs rerunning. At the end of the day all of the |
Beta Was this translation helpful? Give feedback.
-
|
Man, thanks for being patient with me. I don't know why I was being so dense haha. This all now makes sense and I finally found how to disable the hash:
So all I need to do is: gazelle_python_manifest(
name = "gazelle_python_manifest",
modules_mapping = ":modules_map",
pip_repository_name = "pypi",
- requirements = "//:requirements.txt",
)For some reason, I kept thinking that |
Beta Was this translation helpful? Give feedback.
If you specify the requirements file, then it will use the hash to short-circuit the
go_testthat is running to check that the file is up-to-date.However, if you don't specify it, then it will use the bazel action cache to see if the test needs rerunning. At the end of the day all of the
whlfiles are the inputs to the manifest generation. So I am not sure if your explanation why you are using makes sense to me. If your runners' repository cache is hydrated, you should not have to worry about it.