Skip to content

Conversation

repomaa
Copy link
Contributor

@repomaa repomaa commented May 5, 2020

This will avoid changing the mtime of shard.lock and therefor enabling tasks in makefiles that run shards install and depend on shard.yml and shard.lock. Currently those kinds of tasks would be rerun every time because every shards install will write shard.lock (regardless if there are changes or not).

@repomaa repomaa force-pushed the topic/write_on_change branch 2 times, most recently from 9352f98 to fd1424e Compare May 5, 2020 10:35
@waj
Copy link
Member

waj commented May 5, 2020

Hi @repomaa, thanks for this. Actually I think there is a better approach already used in the Install command to avoid re-reading the shard.lock file. It would be probably a good idea to move generate_lockfile? and outdated_lockfile? to Command or even make write_lockfile to call them and do nothing when the file is already up to date.

Comment on lines +45 to +49
File.open("/tmp/shards.log", "a+") do |log|
log.puts File.exists?(path)
log.puts packages.inspect
log.puts from_file(path).inspect if File.exists?(path)
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a leftover? 🙂

@straight-shoota
Copy link
Member

I don't think this solution is sufficient. When there's a dependecy for shard.lock on shard.yml in a Makefile, it needs to be ensured that shard.lock is touched to have a newer mtime than shard.yml. Even if the content didn't change.

@straight-shoota
Copy link
Member

This was eventually superseded by #444. Thanks @repomaa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants