-
-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add project hash to manifest metadata and warn when manifest and project are out of sync #2815
Add project hash to manifest metadata and warn when manifest and project are out of sync #2815
Conversation
also add is_manifest_current check to instantiate
This is a good use case for this PR. Although, I am guessing that most people don't check the CI logs unless the CI job fails, so maybe a warning isn't sufficient for CI? We could do something fancy like check for the presence of the |
Yeah, that's why I exposed
but that requires people to add that to their tests. Detecting |
523fd4f
to
2681963
Compare
Now with a warning in Pkg.status as well
|
Perhaps the warning message could be shorter. This might do
|
Just to point out another way where things can get "out of date" is if you dev a package, and then you work on the deved package and i.e. add a dependency, the original project that deved the package will now have the wrong dependency list in its Manifest and will fail to load the newly added dependency of the deved package. |
Yeah. That issue's covered at package load time by the The issue this tries to overcome is having a manifest which is a false resolve of a project, and instantiate doing as it's told and instantiating the manifest without warning, then the package loading without error, but during runtime hitting some different runtime behavior in a dep because that dep compat narrowed in the project but wasn't re-resolved. That's a highly possible failure mode of projects with checked in manifests, and this PR would make it possible to check for that during PRs |
Is that actually working? I rather get the impression that it tests if the manifest in the temporary test environment is current, which it kind of trivially is.
|
Btw, I think
would be an acceptable API. |
Oh you're right.. yes, not having a default arg would be a reasonable bug fix I think. |
If you just remove the default argument all you have left is |
Yeah, I hadn't remembered the type was Perhaps leave that method, but without a default, and add one that takes a path. Your suggestion seems a reasonable, although this might be better usage to promote in the docs?
|
Maybe we could leave the default arg for the |
I don't have a strong opinion about it, but to me it seems useful to be able to verify the manifest-up-to-dateness for any environment, not only packages. |
True |
See how you like #3701 and if something needs to be changed. It would probably be good with some additional and/or revised tests but I'll wait with that until we are happy with the design changes. |
One of the reasons I was a fan of adding extensible metadata to the manifest was to be able to save a hash of the project state in the manifest, to make it easy to identify when the manifest and project are out of sync. i.e. a project dep entry has been manually added/removed in the toml file, or a compat entry added/changed/removed
Note that the project hash used here only hashes the deps and compat fields of the project, the rest shouldn't affect a resolve, so should be free to change.
One thing this would allow is CI to easily check whether checked-in manifests are valid, as it's easy to forget to update them.
Currently Pkg.instantiate doesn't check compat bounds and just does what the manifest says. This adds a warning.
Todo: