I think it might have to do with buffering of output, but I'm not sure
@snoyberg An odd thing with the display of this package.
https://www.stackage.org/lts-13.26/package/unordered-containers-0.2.10.0
Shows the "latest on hackage" as 0.2.9.0
https://www.stackage.org/lts-13.26/package/unordered-containers-0.2.10.0
Shows the "latest on hackage" as 0.2.9.0
@DanBurton I think I've fixed it with this commit, it still needs to deploy fpco/stackage-server@07f3ef2
I had fun explaining that one to a non-technical family member
If anyone is running into the "mirrors.json is expired" issue, please see this issue for explanation and workaround:
Also, please feel free to weigh in with a vote on that issue.
As you can tell, I'm in favor of disabling the export checks
It is pretty obvious you are in favour of that yes :grin:
I think that, no matter what the security concerns are and how valid they are, it's a bad situation to be in, relying on upstream to keep that JSON file up-to-date when they apparently have let it expire a few times by now.
I think that, no matter what the security concerns are and how valid they are, it's a bad situation to be in, relying on upstream to keep that JSON file up-to-date when they apparently have let it expire a few times by now.
I am trying to formulate a container based workflow to build a haskell project. The idea is to share a container with all project deps (ghc, stack, libs) with other developers, so that when they build the project, only the project's files need to be built and not the deps. This workflow was possible in the 1.9.x stack version, but it is breaking in the 2.x version (all files in the project are built every time stack build is launched within the build container). Is there a workaround to let stack pick up pre-compiled dependencies from the container and still have the project build incrementally?
Maybe I've been using a hacky approach - the package cache in my build image is in /root/.stack (when I build the image with either stack version). The (multi-package) project directory is mounted into the container at /project - when I run stack 1.9 in this directory, stack keeps its work in /project/.stack-work and is able to build incrementally (i.e. when i change some source files in the project and rebuild, only the changed files and packages that depend on it are re-built). In 2.x perhaps because the sqlite db is in /root/.stack, every build rebuilds all the packages in /project.
Is there a better way @DanBurton ?
Ay. Richard Eisenberg wanted to see if there were any stack-specific issues to be discussed with regards to the "provenance qualified package imports" proposal: ghc-proposals/ghc-proposals#115
My sense is that this is all generally build-tool agnostic stuff that's prior to that phase, but it is indeed good to double check
Compiler thinks a type is different depending on where it is referenced
Are there any workarounds in the meantime? Maybe even some tips as to how someone could submit a patch to fix it?
I see
core:test as a separate target from core:lib, so the arrow should look likecore:lib -> testlib:lib -> core:test
But maybe something in stack considers both
core:lib and core:test the same target in some way?
Why is haddock not putting the documentation in the directory specified?
Should I delete / rename the other folder?
I am trying to install https://github.com/litxio/ptghci
running
stack install begins downloading some old ghc version
which is over 200MB!
Is there any option to use my current version instead?
I think you also might have to make sure your local version matches the one in the
resolver version.
✗ stack install
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
ghc-8.6.4: 406.53 KiB / 215.76 MiB ( 0.18%) downloaded...^C
➜ ptghci git:(master) ✗ cat ~/.stack/config.yaml
# This file contains default non-project-specific settings for 'stack', used
# in all projects. For more information about stack's configuration, see
# http://docs.haskellstack.org/en/stable/yaml_configuration/
#
system-ghc: true