-
Notifications
You must be signed in to change notification settings - Fork 842
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
"Right Nothing" printed to the console during setup #2175
Comments
Good point, fixed! |
Then again, perhaps the root issue is not addressed - why are these SHAs missing? |
i'm not too sure about that one. let me know if you want more information from me. |
Oh yeah, to be clear that wasn't a request for more information. More like "this needs further investigation" :) The failure case here is just a fallback to the old behavior where cabal metadata wasn't fixed to a particular revision. So thankfully this shouldn't be very problematic in practice. Good to fix, though! |
I seem to be running into a similar issue, though the output is a bit different - notably the "Left ..." result:
I'm using stack on bitbucket's new "pipelines" feature which executes stack from the haskell:7.10.3 docker image. |
The result of using lts-5.2 is similar but different:
|
Another data point: I saw a bunch of these messages after upgrading stack (from 1.1.0 x86_64 hpack-0.13.0 to 1.1.2 x86_64 hpack-0.14.0) and running stack install. I did stack clean and they went away. |
I see the Edit: I actually see these messages also for other commands, like |
I've seen these messages lately as well, seemingly related to using the latest (Modified instructions from trying to reproduce this bug)
Last month when I ran this with |
I still experience the same bug. |
I'm experiencing the same issue inside a docker container: When I run the cmd
It shows this
And after various similar lines, I get
|
I am new to Haskell and today I attempted to install Haskell for Windows using Stack. However, I get similar errors as in this issue. Number of errors is too long to be copied here, so I provide you with a link instead. While I have clearly run stack install outside a project, I get same errors on the first time I run stack setup. Version 1.1.2, Git revision c6dac65 (3647 commits) x86_64 hpack-0.14.0 |
I was working on getting https://github.com/lukexi/rumpus built on windows yesterday, and also ran into this. I think it just happens when you don't have git. We need to identify when we shouldn't expect to find any SHAs for snapshot packages. |
What I got from looking at the code and hadn't got from reading here: |
Another observation is that when I use Stack to download contents of stack_root, mirror is https://s3.amazonaws.com/hackage.fpcomplete.com, size ends up being 262MB. But when someone else in another country uses Stack, download mirror is Github and contents end up being 451MB. Is the size difference explained by missing cabal/SHA files, or is there something else amiss? |
@KeeperB5 interesting catch! Do you have the two actual URLs for one to look at? |
Well, my index is fetched from https://s3.amazonaws.com/hackage.fpcomplete.com/00-index.tar.gz, but I believe the GitHub mirror had https://github.com/commercialhaskell/all-cabal-hashes. How does Stack pick a mirror and do we have any way to manually select a mirror? |
I've had the "Did not find .cabal file" message pop up in the middle of a build while trying to reproduce #2422:
I can't rule out that I had just started using another
Are you saying you got the "Right Nothing" lines with The "Did not find .cabal file" lines certainly appear on Linux with git installed. |
Further experiments (below) suggest the hashes are part of the snapshot, which makes sense to ensure reproducibility. Hence, we get a log entry for each cabal file in the snapshot considered which was updated since then. Furthermore, I understand the fallback uses a newer cabal file, limiting build reproducibility in the sense of #2217. Under these circumstances, I'd propose to clone the entirety of all-cabal-hashes as a quick fix (currently 215M). This is not fine long-term since bandwidth is limited and since the repo will grow indefinitely, but a better fix wouldn't be immediate. I imagine one could add tags for each snapshot, and stack could fetch those tags when needed, but the tags would be needed remotely. Experiment ResultsUsing lts-6.0, we request for instance a package at revision 5, while
|
@rainbyte In your new issue, can you also add whether |
@KeeperB5: mirroring turns out to not be the problem, but here are some answers. Below's more info than you'd want, saving it for me.
Those are the correct URLs, and they're related but not exactly mirrors, so the size difference is expected. https://github.com/commercialhaskell/all-cabal-hashes has extra metadata on top of https://github.com/commercialhaskell/all-cabal-files, which is a mirror in Git format of the tarball (which is a mirror of the Hackage index on the Amazon cloud).
Basically, mirroring is not geographically based (except whatever optimizations Amazon does internally in S3). Make sure your stack can find your Git and you don't change your config, and stack will use git to update the index incrementally and faster (since you can download only the changes rather than a new snapshot), as described in these docs. The relevant config is described here, https://docs.haskellstack.org/en/latest/yaml_configuration/#package-indices, but I'd avoid changing it usually. With the default config, on both master and 1.1.2, the HTTP download (which is slower) is not used and the Git one is preferred, as long as Git is installed. So either stack doesn't find your Git or you changed your config. SourcesUpdating logic: stack/src/Stack/PackageIndex.hs Lines 214 to 223 in aac2c81
Default config (matching docs): Lines 219 to 228 in aac2c81
|
I've been using Visual Studio and SourceTree which don't need Git to be installed separately. Anyhow, I installed Git for Windows, deleted my stack_root directory, ran stack setup. Now it seems to work as intended, no more errors. Perhaps install documentation should mention requirement for Git? |
Note these were warnings. Should you get further warnings of this kind, you can mostly ignore them—and we'll have a fix by next release. |
Noted. :) But the log does not really specify either way, Usually "The system cannot find the path specified." is treated as an error, so I just followed the suit since I didn't know better. |
+ Ignore installed exe info when it's ambiguous
Fix #2175. * Fetch full history of tags (in particular, `current-hackage`). * Before fetching tags, transition previously shallow repos to be non-shallow with `fetch --unshallow`. * Fetch full history in initial clone, otherwise, we immediately afterwards use `fetch --unshallow`. This means that the initial fetch and later updates require more data, proportional to the entire repository history; however, reducing data usage again is not trivial and would require changes in the layout of all-cabal-hashes, as discussed in #2175.
Stop truncating all-cabal-hashes repo (#2175)
Ouch! I never experienced the problems that prompted this fix but can't proceed now. |
@wiz Is that your usual connection speed? |
I hope not. It downloaded eventually, but in a pinch that got me nervous. |
Now there's real pain. My CI have this restricted uplink and should start from scratch each time 😔 |
@wiz: Can't you cache the |
with
when i attempt a setup i see:
it's mildly unfortunate that
Right Nothing
is printed here.introduced a few weeks ago by f483e82#diff-2068556e565acc62de252ac25ed550c4R288
The text was updated successfully, but these errors were encountered: