Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

ensure changes mtime every time it is run causing go to take longer to rebuild #1391

Closed
ashb opened this issue Nov 20, 2017 · 2 comments
Closed

Comments

@ashb
Copy link

ashb commented Nov 20, 2017

As part of my Makefile I have a dep ensure --vendor-only step before any other commands. However this causes all dependent packages to be built as the ensure step recreates all files and doesn't preserve any modification times.

I tried adding an os.Chtimes into the internal/fs copyFile method but given that copies from a temp directory it didn't make any difference in trying to preserve mtimes for files.

I would like the mtime to be "stable" -- I don't mind if this is based on the commit date of the revision we are at, or even the clone date of the cache under pkg/dep/sources, or even based on the mtime of Gopkg.toml/.lock, just so long as it is stable.

What version of dep are you using (dep version)?

(themisto src/github.com :*+)% brew link dep
dep versLinking /Users/ash/.homebrew/Cellar/dep/0.3.2... i1 symlinks created
o(themisto src/github.com :*+)% dep version
dep:
 version     : devel
 build date  :
 git hash    :
 go version  : go1.9.1
 go compiler : gc
 platform    : darwin/amd64

(installed via homebrew)

What dep command did you run?

dep ensure --vendor-only -v; cd vendor; go install -v ./github.com/jteeuwen/go-bindata/go-bindata

What did you expect to see?

It not recompile the go-bindata package as nothing has changed

What did you see instead?

It recompiling.

@jmank88
Copy link
Collaborator

jmank88 commented Nov 20, 2017

If I understand correctly, this shouldn't be a problem with Go 1.10. From: https://tip.golang.org/doc/go1.10#build

The go build command now detects out-of-date packages purely based on the content of source files, specified build flags, and metadata stored in the compiled packages. Modification times are no longer consulted or relevant.

More: https://groups.google.com/forum/#!topic/golang-dev/EZtZsJG35ZM

@sdboyer
Copy link
Member

sdboyer commented Nov 28, 2017

as @jmank88 noted, i suspect this problem will largely go away in 1.10. we'll also be able to avoid regenerating vendor unless it's absolutely necessary once we have #121.

that said, i wouldn't be opposed to a PR that made us avoid clobbering mtimes all over the place, even when we do regenerate parts of vendor. it might not add much and could end up being prohibitively difficult to accomplish...but it does feel like it might make us better citizens 😄

however, given that 1.10 and #121 represent solutions that will take care of this, i'm gonna close this out. if someone actually wants to undertake this possibly-Quixotic task, then we can reopen 😉

@sdboyer sdboyer closed this as completed Nov 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants