Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Warnings when parsing lock file #4789

Closed
snoyberg opened this issue Apr 30, 2019 · 2 comments
Closed

Warnings when parsing lock file #4789

snoyberg opened this issue Apr 30, 2019 · 2 comments
Milestone
Stack 2

Comments

@snoyberg
Copy link
Contributor

Actions:

  1. Using a stack executable from commit 595e9ea
  2. rm -f stack.yaml.lock
  3. Run stack build in the Stack repo at that same commit
  4. Get some warnings
$ stack build 
Using archive from https://github.com/snoyberg/filelock/archive/97e83ecc133cd60a99df8e1fa5a3c2739ad007dc.tar.gz without a specified cryptographic hash
Cached hash is 78332e0d964cb2f24fdbb6b07c2a6a84a029c4fe540a0435993c85ad58eab051, file size 9526
For security and reproducibility, please add a hash and file size to your configuration
Using archive from https://github.com/snoyberg/filelock/archive/97e83ecc133cd60a99df8e1fa5a3c2739ad007dc.tar.gz without a specified cryptographic hash
Cached hash is 78332e0d964cb2f24fdbb6b07c2a6a84a029c4fe540a0435993c85ad58eab051, file size 9526
For security and reproducibility, please add a hash and file size to your configuration

The missing cryptographic hash isn't true: the stack.yaml.loc does in fact include the sha256 and filesize of the tarball. Running stack build a second time generates slightly different warnings:

$ stack build 
Warning: /Users/michael/Documents/stack/stack.yaml.lock: Unrecognized fields in UnresolvedPackageLocationImmutable.PLIArchive: cabal-file, name, pantry-tree, version
Using archive from https://github.com/snoyberg/filelock/archive/97e83ecc133cd60a99df8e1fa5a3c2739ad007dc.tar.gz without a specified cryptographic hash
Cached hash is 78332e0d964cb2f24fdbb6b07c2a6a84a029c4fe540a0435993c85ad58eab051, file size 9526
For security and reproducibility, please add a hash and file size to your configuration

Looks like this might be a bug in the parsing or rendering of a PLIArchive. CC @qrilka
@snoyberg snoyberg added this to the Stack 2 milestone Apr 30, 2019
snoyberg added a commit that referenced this issue Apr 30, 2019
@snoyberg
Fix some misplaced parse warnings #4789
d4035f0
@snoyberg snoyberg mentioned this issue Apr 30, 2019
Merged
snoyberg added a commit that referenced this issue May 1, 2019
@snoyberg
Fix some misplaced parse warnings #4789
3f05443 
Instead of FromJSON instances for Repo and PackageMetadata, use the
Data.Aeson.Extended mechanisms to properly track which fields are used.
snoyberg added a commit that referenced this issue May 1, 2019
@snoyberg
Get package name from completed information #4789
38826df 
The completed package information already contains the package name,
bypassing the need for a package completion call if the cache (lock
file) already contains that information. This bypasses a spurious
warning about lacking cryptographic hashes, and likely improves
performance, for the repo and archive cases.

This wasn't discovered initially because the Hackage use case never had
an overhead: the specification of a RPLIHackage already contains the
package name in all cases.
@snoyberg
Copy link
Contributor Author

snoyberg commented May 1, 2019

I've opened up a PR (#4790) for the warnings during the parsing. That addresses "unrecognized fields" bit above by using the Data.Aeson.Extended machinery better.

I've opened up a second PR (#4791) for the warnings about "without specified cryptographic hash." The issue there was that we were looking up the package name from the raw information, instead of using the completed information.

Once both PRs are merged we can close this issue.

snoyberg added a commit that referenced this issue May 1, 2019
@snoyberg
Merge pull request #4790 from commercialhaskell/4789-improved-from-js…
ba6037a 
…on-instances

Fix some misplaced parse warnings #4789
snoyberg added a commit that referenced this issue May 2, 2019
@snoyberg
Merge pull request #4791 from commercialhaskell/4789-package-name-fro…
28138a9 
…m-completed

Get package name from completed information #4789
@snoyberg
Copy link
Contributor Author

snoyberg commented May 2, 2019

Both PRs and merged, closing

@snoyberg snoyberg closed this as completed May 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Stack 2
Development

No branches or pull requests
1 participant
@snoyberg