> absolutely! and we are actually planning to p...
# general
h
absolutely! and we are actually planning to phase out v1 ./pants filedeps in favor of a faster version at some point, which is currently available with ./pants fast-filedeps
I don’t think Serge is asking about changing how
filedeps
behaves. Rather, he wants to change how cache fingerprinting works in general and was looking at
--filedeps-absolute
as a possible solution that ended up being irrelevant
a
yes, and v2 filedeps has a completely different caching schema that is aware of things like relative/absolute paths because snapshots are fingerprinted!
so i was thinking that it would be a way to avoid further time used up with v1 caching bugs (which is the biggest issue with v1 anyway)
and i would also like to avoid people starting to write a lot of custom workarounds now for v1 filedeps when they will likely be invalidated once v2 filedeps is up to par
but @little-salesmen-78240 we're not planning to remove v1
./pants filedeps
anytime soon and you will have plenty of advance notice + migration help if/when we do :)
h
Well, to clarify, the migration will happen behind the scenes. Once
./pants filedeps2
reaches feature parity with
filedeps
, we will remove the V1 implementation and replace it with the V2 one. Users will still have the same API, but better caching and the ability to run the goal through remote execution
a
yes!
but i wanted to make it clear that we do not break our users' repos!