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

To prevent download ghc when using stack clean. #4268

Merged
merged 10 commits into from
Nov 16, 2018
Merged

To prevent download ghc when using stack clean. #4268

merged 10 commits into from
Nov 16, 2018

Conversation

waddlaw
Copy link
Contributor

@waddlaw waddlaw commented Aug 27, 2018

stack clean always download the ghc even if it already deleted.

$ stack --version
Version 1.10.0, Git revision 65dd1d673a75d867325bb1c70f5170386900dd80 (dirty) (6415 commits) x86_64 hpack-0.29.6

$ stack clean
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Preparing to download ghc-7.10.2 ...^C

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!

@dbaynard
Copy link
Contributor

Thanks, @waddlaw — this relates to #4181, correct?

I'm going to review, now.

Copy link
Contributor

@dbaynard dbaynard left a comment

Choose a reason for hiding this comment

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

Thanks again.

There are 2 major issues which must be resolved.

  1. The check in the stack code base that there is a valid GHC is now made optional, but downstream code has not been changed to reflect this. This makes that code more fragile. I can't speak for everyone on the project, though, so I'm getting another opinion.

  2. This PR duplicates certain code paths due to bugs which have been (mostly) resolved. I've pinged @mgsloan who should be able to confirm this. Most of the additions to the code here fall into this category.

@@ -631,8 +631,8 @@ cleanCmd opts go =
-- See issues #2010 and #3468 for why "stack clean --full" is not used
-- within docker.
Copy link
Contributor

Choose a reason for hiding this comment

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

So interestingly, both #2010 and #3468 have been closed — but #3471 is still open.

@mgsloan can this be simplified, now?


withBuildConfigExt
:: Bool
-> Bool -- ^ If perform the stack clean
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm concerned by the boolean blindness, here. The following types would be helpful.

data WithDocker
  = SkipDocker
  | WithDocker

data IsClean
  = NotClean
  | IsClean

But see my comments on whether the docker checks are still necessary.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed, making another type that's iso to Bool is usually better.

To me the naming seems too purpose specific. I think it makes sense to instead have the name correspond to the behavioral change. That, is the name should specify whether or not it requires ghc to be installed.

@@ -127,7 +129,7 @@ withBuildConfigAndLock
-> (Maybe FileLock -> RIO EnvConfig ())
-> IO ()
withBuildConfigAndLock go inner =
withBuildConfigExt False go Nothing inner Nothing
withBuildConfigExt False False go Nothing inner Nothing

-- | See issue #2010 for why this exists. Currently just used for the
Copy link
Contributor

Choose a reason for hiding this comment

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

See comment below

withBuildConfigExt False True go Nothing inner Nothing

-- | See issue #2010 for why this exists. Currently just used for the
-- specific case of "stack clean --full".
Copy link
Contributor

Choose a reason for hiding this comment

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

See comment below

@@ -235,7 +235,7 @@ setupEnv mResolveMissingGHC = do
, soptsGHCJSBootOpts = ["--clean"]
}

(mghcBin, compilerBuild, _) <- ensureCompiler sopts
(mghcBin, compilerBuild, _) <- if bcClean bconfig then pure (Nothing, CompilerBuildStandard, False) else ensureCompiler sopts
Copy link
Contributor

Choose a reason for hiding this comment

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

This change is making the presence of a compiler optional, and so the code should reflect this — yet this implementation does not.

Subsequent code uses the compilerBuild option; it is faked here, making that code more fragile. It might be better that it has type Maybe CompilerBuild here; in this way the possible absence of a compiler is reflected in the type system. This then propagates to EnvConfig which I believe will need changes.

@dbaynard dbaynard requested a review from mgsloan August 27, 2018 19:40
@mgsloan
Copy link
Contributor

mgsloan commented Aug 27, 2018

@dbaynard I don't recall the details of this part of the code, so it's best just to look at what it's doing. I agree about avoiding use of Bool. I left a comment about naming considerations - I imagine that skipping compiler installation is not unique to the clean command.

@waddlaw
Copy link
Contributor Author

waddlaw commented Aug 31, 2018

@dbaynard Thank you for reviewed!

this relates to #4181, correct?

I don't know that directly related to it. But, bypassed the ghc download at least.

There are 2 major issues which must be resolved.

OK. I will try to fix it.

I left a comment about naming considerations - I imagine that skipping compiler installation is not unique to the clean command.

That makes sense.

@waddlaw
Copy link
Contributor Author

waddlaw commented Sep 2, 2018

@dbaynard Are you sure about this?

@mihaimaruseac
Copy link
Contributor

Ping on this, as it's becoming stale.

@dbaynard
Copy link
Contributor

dbaynard commented Nov 7, 2018

Ah, thank you for bearing with me — I must have looked at this 3 or 4 times and didn't notice the new commits.

I'll check shortly, and then it may be worth looking at the possibilities for #4390.

Copy link
Contributor

@dbaynard dbaynard left a comment

Choose a reason for hiding this comment

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

OK, I'm going to try to implement an integration test, then merge.

@@ -535,7 +548,7 @@ data EnvConfig = EnvConfig
-- ^ The actual version of the compiler to be used, as opposed to
-- 'wantedCompilerL', which provides the version specified by the
-- build plan.
,envConfigCompilerBuild :: !CompilerBuild
,envConfigCompilerBuild :: !(Maybe CompilerBuild)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
,envConfigCompilerBuild :: !(Maybe CompilerBuild)
,envConfigCompilerBuild :: !(Maybe !CompilerBuild)

I think we want to force the whole thing.

@dbaynard dbaynard merged commit b139364 into commercialhaskell:master Nov 16, 2018
@waddlaw
Copy link
Contributor Author

waddlaw commented Nov 17, 2018

@dbaynard thanks!

@waddlaw waddlaw deleted the fix-clean branch November 17, 2018 01:35
@dbaynard
Copy link
Contributor

@waddlaw have you seen #4390? Would you like to try to implement that?

@waddlaw
Copy link
Contributor Author

waddlaw commented Nov 17, 2018

I’m more than happy to help you :) I'll do that.

@dbaynard
Copy link
Contributor

Great!

@qrilka
Copy link
Contributor

qrilka commented Nov 21, 2018

I have note about this PR - SkipDownloadCompiler doesn't quite reflect what's going on when this value get passed: it turns off any compiler checks. I'm not sure what could be a more suitable name here but it's better to have something more explicit and probably some haddocks could be added

@dbaynard
Copy link
Contributor

Yes — any suggestions welcome. In particular, there is #4405 which builds on it. I'll note your comment in my review. So SkipCheckCompiler would be a more precise name?

@qrilka
Copy link
Contributor

qrilka commented Nov 22, 2018

Thanks, sounds good to me though word order is confusing a bit, I think SkipCompilerCheck reads better, what do you think?

@waddlaw
Copy link
Contributor Author

waddlaw commented Nov 23, 2018

Thanks @qrilka
It naming so nice. Would you like me to contain this change into #4405? or submit another pr?

@qrilka
Copy link
Contributor

qrilka commented Nov 23, 2018

@waddlaw I think separate commit in #4405 with this change will be OK

@qrilka
Copy link
Contributor

qrilka commented Jan 5, 2019

@dbaynard it looks like #4480 uncovered problem with this PR and I'm not yet clear how to resolve it: by default stack clean does shallow cleanup deleting dist directories for project packages but to get proper dist directories Stack consults ghc-pkg to get Cabal version and without GHC installed (or not put into the current $PATH) it fails.
I think we should be able to go around that if we could use global packages retrieved from https://github.com/commercialhaskell/stackage-content/blob/master/stack/global-hints.yaml but that changes Stack logic a bit. Do we have any guarantees that global-pkg-db won't contain other Cabal version?
BTW just today I have a Twitter discussion about using arbitrary Cabal with earlier Stackage LTSes - https://twitter.com/qrilka/status/1081538344214020096

@dbaynard
Copy link
Contributor

dbaynard commented Jan 6, 2019

I found the lack of documentation on this precise point really disappointing — I had to go digging through the code and run some tests myself in order to see what stack clean actually did.

Presumably, stack clean ought to remove the directory corresponding to the compiler's Cabal version (that's how it has been implemented). It then should not remove directories corresponding to other 'Cabal' versions. Is that correct?

All this information ought to be in the stack configuration — presumably if somebody has overridden the cabal version, that override would be there? In which case we can use global-hints.yaml. Otherwise we may have to choose between downloading GHC and deleting the wrong dist directory.

As an aside: the integration test has a false positive, related to #4468, which I'm yet to fix.

@qrilka
Copy link
Contributor

qrilka commented Jan 7, 2019

You're mostly correct in your analysis. There's only 1 thing to note: currently Cabal version is more or less fixed for an LTS (the one shipped with GHC gets used) and Veronika (from the Twitter discussion I linked above) started a fresh issue #4488 to discuss ways around that limitation of Stack.

@dbaynard
Copy link
Contributor

dbaynard commented Jan 7, 2019

Right so if that changes our assumption about global-hints.yaml has to change?

I'll comment on the relevant issues, then. I'm quite confused by the various interactions with stack and Cabal — may seek some clarifications there, too.

But for now, given stack path --dist-dir (which picks the relevant Cabal library) requires ghc-pkg I'll start digging around there.

@qrilka
Copy link
Contributor

qrilka commented Jan 11, 2019

Somehow missed this message @dbaynard but make it maybe a bit more clear - I don't think we could change our assumptions about global-hints.yaml - that file says which libraries come with a specific GHC version and we use that to get global libraries which go into the smGlobal field of SourceMap type. As for Cabal version - it could be overridden and if we'll try to address concerns in #4488 we'll use that new Cabal version instead of a "global" one which could come either from ghc-pkg results or global-hints.yaml. Does this make sense?

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.

5 participants