wit-deps always rewrites dependencies

[jsantell]

Running wit-deps always rewrites deps/* even when the sources haven't changed.

These redundant outputs has the consequence of an updated timestamp, invalidating caches in more complex builds. It'd be fantastic if the generated deps are not written if not needed.

From the readme, I'd expect no writes if there are no changes:

wit-deps is lazy by default and will only fetch/write when it absolutely has to

STR

tmp/foo/wit/foo.wit

package tmp:foo@0.0.1;

world main {
  import tmp:printer/funcs@0.0.1;
}

tmp/foo/wit/deps.toml

printer = "../../printer/wit"

tmp/printer/wit/printer.wit

package tmp:printer@0.0.1;

interface funcs {
  print: func(msg: string);
}

world tmp {
  export funcs;
}

When running cd tmp/foo && wit-deps, tmp/foo/wit/deps/printer/printer.wit is always updated. The tmp/foo/wit/deps.lock file, however, is only written to if needed.

[rvolosatovs]

Thanks for the report @jsantell, that makes sense - wit-deps uses the wit/deps directory as the "work" directory. Currently "laziness" only extends to URL-based operation, but not path-based one.

In your example it would first copy ../../printer/wit into wit/deps/printer and only then compute the lock.

So the fix there would be to either:

• use a different "work" directory (e.g. a temporary directory), contents of which are moved to wit/deps

or:

• computing the lock ahead-of-time

or:

• check the contents of each file before writing it

Somewhat refs #157

Would you be interested in contributing this feature @jsantell ?

Otherwise, could only checking the deps.lock contents/timestamp instead address you issue?

[rvolosatovs]

@jsantell could you test if #204 addresses your use case?

Update: I've went ahead and released that change in 0.4.0, since it was a tech debt anyway, that was meant to be addressed

[jsantell]

it looks like 0.4.0/#204 did the trick! Thank you so much