Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Magnus Therning
    @magthe
    Ah, OK... I'm not sure where I would have been able to find that information without asking though.
    Кирилл Заборский
    @qrilka_twitter
    yes, there is such a problem with it
    Michael Snoyman
    @snoyberg

    If anyone is running into the "mirrors.json is expired" issue, please see this issue for explanation and workaround:

    commercialhaskell/stack#4928

    Also, please feel free to weigh in with a vote on that issue.

    Magnus Therning
    @magthe
    Ouch... the workaround is OK for local builds, but a bit tedious when trying to get CI builds going again :/
    Michael Snoyman
    @snoyberg
    You can put that config in your stack.yaml as well if you want
    As you can tell, I'm in favor of disabling the export checks
    Magnus Therning
    @magthe
    Ah, yes, I just realized it can go into the project's stack.yaml too.
    Magnus Therning
    @magthe
    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.
    Aditya Manthramurthy
    @donatello
    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?
    Dan Burton
    @DanBurton
    I believe the same workflow should still be possible, with the caveat that a cache built with stack 1.9 is not usable by stack 2.x; the cache must be built by stack 2.x if it is to be used by stack 2.x.
    Aditya Manthramurthy
    @donatello
    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 ?
    Dan Burton
    @DanBurton
    I'm not familiar enough with the pantry-related changes to give a good answer to that. Perhaps @snoyberg can help? ^
    Michael Snoyman
    @snoyberg
    I'd recommend testing with the latest on stable, we made some changes that affect caching a bit, check out the ChangeLog
    gbaz
    @gbaz
    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
    Cary Robbins
    @carymrobbins
    This bug brings much sadness into my life - commercialhaskell/stack#4786
    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?
    Michael Snoyman
    @snoyberg
    @carymrobbins any chance that there are cyclic dependencies at play here?
    Cary Robbins
    @carymrobbins
    @snoyberg I think technically no, there shouldn't be, unless this introduces one -
    • A stack project with two packages core and testlib
    • testlib:lib depends on core:lib
    • core:test depends on testlib:lib
    I see core:test as a separate target from core:lib, so the arrow should look like
    core:lib -> testlib:lib -> core:test
    But maybe something in stack considers both core:lib and core:test the same target in some way?
    hovind
    @hovind
    Hi, folks! stack build puts things in .stack-work/install/x86_64-linux-tinfo6, does anyone know how I can generate the arch-vendor-abi triplet (in this case x86_64-linux-tinfo6) in a portable manner?
    TrueBoxGuy
    @TrueBoxGuy
    image.png
    Why is haddock not putting the documentation in the directory specified?
    Should I delete / rename the other folder?
    Dmitri Zaitsev
    @dmitriz
    Hi folks! Does anyone know how to make stack use the current ghc?
    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?
    Magnus Therning
    @magthe
    I think you also might have to make sure your local version matches the one in the resolver version.
    Dmitri Zaitsev
    @dmitriz
    @magthe Thanks, I have actually found it and tried but sadly the download is running nevertheless
    ✗ 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
    which ghc 
    ~/.ghcup/bin/ghc
    Magnus Therning
    @magthe
    And what version is that pre-installed ghc?
    Dmitri Zaitsev
    @dmitriz
    @magthe The latest version:
    ~ ghci -V
    The Glorious Glasgow Haskell Compilation System, version 8.6.5
    ➜  ~ ghc -V 
    The Glorious Glasgow Haskell Compilation System, version 8.6.5
    Magnus Therning
    @magthe
    I'm not sure how picky stack is, but it could reject your 8.6.5 because the version in the resolver is 8.6.4.
    Dmitri Zaitsev
    @dmitriz
    @magthe Ok, I have managed to download those versions with ghcup that thankfully have been accepted by stack (that wasn't able to download them). So I am fine with any version that is available with ghcup but there seem to be only few.
    Jennifer Wilcox
    @Nitori-
    Hey everyone, I have a small question.
    I'm working on a small "auxiliary" command for stack (i.e. you call your package "stack-foo" and "stack foo" will invoke it)
    Is there any opinion on where I should keep the custom configuration for such a command? I'd be inclined to put it in stack.yml but I don't know if that would be poor form
    Casper Thule
    @CThuleHansen
    Is there a way to see where the binaries are stored after stack build?
    Casper Thule
    @CThuleHansen
    hmm seems not
    Kirill Zaborsky
    @qrilka
    why not?
    qrilka@qdesktop ~/ws/h/hatrace $ ls $(stack path --local-install-root)/bin
    hatrace
    Dan Burton
    @DanBurton

    @CThuleHansen you can also try

    stack exec which mybin

    replacing mybin with the binary you are trying to find

    Casper Thule
    @CThuleHansen
    @DanBurton tried, no luck
    using local-install-root
    to path