Add lock-files script #17
Conversation
|
There is a fair bit of shell here, I geeked out a bit, might not be seen as useful. |
|
If this goes through my next task will be try to bring the |
|
|
||
| # Make a best effort at creating a minimal lock file. | ||
| rm --force Cargo.lock | ||
| cargo +nightly check --all-features -Z minimal-versions |
There was a problem hiding this comment.
In 65a74a1:
It seems like this script needs this line to fail in order to be useful. But I believe this fails on every single one of our repos becaue our minimal dependencies themselves don't specify their minimal dependencies correctly.
Though I guess I haven't tried it for some of the new leaf crates..
There was a problem hiding this comment.
It seems like this script needs this line to fail in order to be useful.
What do you mean by this? My main idea behind this script was that if this succeeds then win and one doesn't have to have the -Z command in shell history or in mind. And if it this fails the script documents my lazy 'just duplicate recent'. But since the script lives in an obscure repo is this even useful, I don't know?
I used -Z minimal-versions recently and it worked, to my surprise (maybe in bech32, but not sure).
There was a problem hiding this comment.
I used
-Z minimal-versionsrecently and it worked, to my surprise (maybe inbech32, but not sure).
Ooo, nice.
I think the MSRV update to 1.63 solved a lot of our dependency compatibility issues.
And if it this fails the script documents my lazy 'just duplicate recent'
I don't think it's too useful as documentation because it's inside a script in a fairly obscure repo.
I also think we should move away from "duplicate the recent lockfile" to "just don't have a minimal lockfile". This will clearly signal which repos still need somebody to do the hard work of running -Z minimal then patching everything up.
There was a problem hiding this comment.
I guess, if the script were to try using -Zminimal, and on failure, output a warning and not produce the lockfile, that'd be pretty cool.
I guess we also need to check that the "recent" lockfile produced by cargo update works with MSRV. Again, in my experience it almost never does. And we need to hard fail if neither lockfile can be produced.
There was a problem hiding this comment.
Good ideas, will re-spin.
There was a problem hiding this comment.
Currently the script doesn't fail correctly in workspace because cargo check in a workspace does not exit with non-zero if the last crate builds successfully, I couldn't find a way to make it do so.
I also think we should move away from "duplicate the recent lockfile" to "just don't have a minimal lockfile".
Leaving this for another day.
tcharding
force-pushed
the
09-20-lock-files
branch
from
65a74a1
to
58e9904
Compare
Add a script to create and update the minimal and recent lock files. On the way create a `stdlib.sh` script to reduce code duplication and also a `template.sh` to make writing the next script easier. Note I could not get `flag_verbose` to work with sourcing the `stdlib` script without exporting a global variable which I didn't do so as not to pollute the environment. If this merges we can remove the `update-lock-files.sh` script from other repos and use this new script.
tcharding
force-pushed
the
09-20-lock-files
branch
from
58e9904
to
50c90c3
Compare
Add a script to create and update the minimal and recent lock files. On the way create a
stdlib.shscript to reduce code duplication and also atemplate.shto make writing the next script easier.Note I could not get
flag_verboseto work with sourcing thestdlibscript without exporting a global variable which I didn't do so as not to pollute the environment.If this merges we can remove the
update-lock-files.shscript from other repos and use this new script.