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.

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

Support .tar archives #3647 #3655

Merged
merged 2 commits into from
Dec 15, 2017
Merged

Support .tar archives #3647 #3655

merged 2 commits into from
Dec 15, 2017

Conversation

snoyberg
Copy link
Contributor

Note: Documentation fixes for https://docs.haskellstack.org/en/stable/ should target the "stable" branch, not master.

Please include the following checklist in your PR:

  • Any changes that could be relevant to users have been recorded in the ChangeLog.md
  • The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

@snoyberg snoyberg changed the base branch from master to stable December 14, 2017 08:24
@@ -120,14 +120,20 @@ resolveSinglePackageLocation projRoot (PLArchive (Archive url subdir msha)) = do
archive <- fmap Zip.toArchive $ liftIO $ L.readFile fp
liftIO $ Zip.extractFilesFromArchive [Zip.OptDestination
(toFilePath dirTmp)] archive
tryTar = do
logDebug $ "Trying to untar (no ungzip) " <> T.pack fp
liftIO $ withBinaryFile fp ReadMode $ \h -> do
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the current code will end up reading the file 3 times. Though perhaps it wouldn't be as bad as that, since the decoding should fail quickly.

Might be worth pulling withBinaryFile + hGetContents out to the top level. Could increase memory residency, but that seems fine.

I'd actually lean towards using something like L.readFile, but I guess the exception handling isn't so great there w.r.t. closing the handle. This is a side note, but I'm a bit surprised the code wouldn't use a weak pointer and also close the handle of the lbs is GCed.

Note that L.readFile is used above in the unzip code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd much rather have multiple file reads than potentially unbounded memory usage, though in this case unbounded is basically impossible: parsing should fail immediately. I'll update this to do one read. Note that on master, I've already changed this to use a new helper withLazyFile instead of explicit withBinaryFile and hGetContents.

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool, makes sense!

Why merge this into stable instead of master?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking that it's a small enough change to include in a patch. Since we're actively planning on such a patch, I'm trying to include as many minor, backwards compatible changes as I can. You think it's better to put this one on master?

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems fine to me to have it in the patch version to, just curious

Copy link
Contributor

@mgsloan mgsloan left a comment

Choose a reason for hiding this comment

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

LGTM. Just one comment about efficiency that probably doesn't matter all that much.

@snoyberg snoyberg merged commit 6125a80 into stable Dec 15, 2017
@snoyberg snoyberg deleted the 3647-uncompressed-tarballs branch December 15, 2017 09:31
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.

2 participants