Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    Dan Burton

    @CThuleHansen you can also try

    stack exec which mybin

    replacing mybin with the binary you are trying to find

    Casper Thule
    @DanBurton tried, no luck
    using local-install-root
    to path
    Ben MacAdam
    Hi there, I've been trying to get stack working on a university lab for a few days now - the main issue is that each user's environment takes up about 8GB of space. Is there any way to set a global stack root? I'm trying to share the same .stack folder between two users on my personal laptop and I'm getting permissions errors.
    Balter Notz
    Hello, I got a problem
    when I run stack setup,
    Exception while reading snapshot from lts-14.12:
    HttpExceptionRequest Request {
      host                 = ""
      port                 = 443
      secure               = True
      requestHeaders       = [("User-Agent","Haskell pantry package")]
      path                 = "/commercialhaskell/stackage-snapshots/master/lts/14/12.yaml"
      queryString          = ""
      method               = "GET"
      proxy                = Nothing
      rawBody              = False
      redirectCount        = 10
      responseTimeout      = ResponseTimeoutDefault
      requestVersion       = HTTP/1.1
     (InternalException (HostCannotConnect "" [Network.Socket.connect: <socket: 13>: does not exist (Connection refused)]))
    Balter Notz
    My ~/.stack/config.yml file
    setup-info: ""
      - download-prefix:
            - 0a5c7ea47cd1b15f01f5f51a33adda7e655bc0f0b0615baa8e271f4c3351e21d
            - 1ea9ba32c526d1cc91ab5e5bd364ec5e9e8cb67179a471872f6e26f0ae773d42
            - 280b10153a522681163658cb49f632cde3f38d768b736ddbc901d99a1a772833
            - 2a96b1889dc221c17296fcc2bb34b908ca9734376f0f361660200935916ef201
            - 2c6c3627bd6c982990239487f1abd02e08a02e6cf16edb105a8012d444d870c3
            - 51f0161b906011b52c6613376b1ae937670da69322113a246a09f807c62f6921
            - 772e9f4c7db33d251d5c6e357199c819e569d130857dc225549b40845ff0890d
            - aa315286e6ad281ad61182235533c41e806e5a787e0b6d1e7eef3f09d137d2e9
            - fe331502606802feac15e514d9b9ea83fee8b6ffef71335479a2e68d84adc6b0
            key-threshold: 3 # number of keys required
            # ignore expiration date, see
            ignore-expiry: no
    Balter Notz
    btnz@vmubuntuserver:~$ wget
    --2019-10-30 02:12:07--
    Resolving (
    Connecting to (||:443... failed: Connection refused.
    btnz@vmubuntuserver:~$ wget
    --2019-10-30 02:12:31--
    Resolving (
    Connecting to (||:443... failed: Connection refused.
    btnz@vmubuntuserver:~$ wget
    --2019-10-30 02:14:46--
    Resolving (
    Connecting to (||:443... failed: Connection refused.
    btnz@vmubuntuserver:~$ wget
    --2019-10-30 02:16:26--
    Balter Notz
    btnz@vmubuntuserver:~$ stack update
    Selected mirror
    Downloading root
    Selected mirror
    Downloading timestamp
    Downloading snapshot
    Downloading mirrors
    Cannot update index (no local copy)
    Downloading index
    Updated package index downloaded
    Calculating hashes to check for hackage-security rebases or filesystem changes
    No old cache found, populating cache from scratch
    Populating cache from file size 632057344, hash 12df935d511eb0000b2755731539acf68d09cd10539b17f83f7e5ac9c37edc99
    Populating package index cache ...
    Package index cache populated
    btnz@vmubuntuserver:~$ stack setup
    Warning: Unrecognized field in GHCDownloadInfo: version
    Preparing to install GHC to an isolated location.
    This will not interfere with any system-level installation.
    Downloaded ghc-8.6.5.                                      
    rts-1.0: Warning: .:466:1: The field "hugs-options" is deprecated. hugs isn't supported anymore
    Installed GHC.    
    stack will use a sandboxed GHC it installed
    For more information on paths, see 'stack path' and 'stack exec env'
    To use this GHC and packages outside of a project, consider using:
    stack ghc, stack ghci, stack runghc, or stack exec
    Javier Neira
    @benjamin-macadam setting $STACK_ROOT?
    Taine Zhao
    Can you guys save me? idris must match ==1.3.2, but the stack configuration has no specified version (latest matching version is 1.3.2)
    Paolo G. Giarrusso
    @thautwarm do you need to add idris to your extra-deps? if not, I guess you'll need to provide more info :-)
    Taine Zhao
    I hadn't done it. In fact I know I can do this, but I just feel like to avoid changing stack.yaml...
    After all, I think I've already specified the version info of that dependency.
    Taine Zhao
    However, I did now and I still want to know how to solve it without chaning stack.yaml...
    Magnus Therning
    Well, idris seems to not be included in Stackage, so I believe you are pretty much forced to mention it in stack.yaml if you depend on it.
    Taine Zhao
    Understood. I forgot the stackage-related stuffs, and I now think it makes a lot of sense!
    Cary Robbins
    I may have asked about this before, but is there a programmatic way for accessing the stackage API to determine resolver metadata? e.g. some sort of list-resolvers endpoint
    Seems from the routes file there's not really anything like this exposed?
    Coding Horribly

    Hi! I'm new to Haskell, and I just used Stack to install Yesod. There were a bunch of warnings, and I'm trying to figure out if they're warning about Stack itself or Yesod (or both?). I'd be happy to try to help clean some of them up, if I can. Two examples:

    x509-validation     > /tmp/stack13015/x509-validation-1.6.11/Data/X509/Validation.hs:34:1: warning: [-Wunused-imports]
    x509-validation     >     The import of ‘Control.Applicative’ is redundant
    x509-validation     >       except perhaps to import instances from ‘Control.Applicative’
    x509-validation     >     To import instances alone, use: import Control.Applicative()
    x509-validation     >    |                                   
    x509-validation     > 34 | import Control.Applicative        
    x509-validation     >    | ^^^^^^^^^^^^^^^^^^^^^^^^^^        
    x509-validation     >

    I figure that one (the one above) is validating Yesod, and found that in Yesod. But what about:

    unix-time           > /tmp/stack13015/unix-time-0.4.7//usr/include/features.h:184:3: error:      
    unix-time           >      warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
    unix-time           >      # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
    unix-time           >        ^~~~~~~                                                             
    unix-time           >     |                                                                      
    unix-time           > 184 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
    unix-time           >     |   ^


    Paolo G. Giarrusso
    Aren't those in the packages listed on the left column?
    So, neither stack nor yesod?
    And fixing the second requires C/UNIX experience
    Coding Horribly
    Okay, I'm pretty new to all of this, I thought x509-validation was a Stack validation library, but it's actually a separate library that Stack is leveraging?
    Javier Neira
    @codinghorribly they are libraries that yesod depends on, stack should build all dependencies before even to start build yesod itself
    dont worry, at beginning it could be a little it difficult :smile:
    the first one is a warning and i guess it didnt stop the building (so other libraries was built after it)
    Javier Neira
    the second one is a error and it stopped the build, so stack could not finish the entire process
    haskell libs can use c header files and unix-time uses it extensively, i would open an issue in the github repo:
    including in the issue the log of the error and the version of you os would help maintainers

    Why does stack (and also cabal?) have such a limitation?

    Cannot use 'stack ghci' with both file targets and package targets

    I got annoyed when I tried to load my package and its example code (not included in the package) at the same session of stack ghci.
    I learned it can be easily avoided by typing :add path/to/example.hs after launching stack ghci.
    So why doesn't stack do it automatically?


    Anyone with experience building static binaries with stack?
    I'm getting a pesky

    <command line>: User-specified static library could not be loaded (/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/libpgport.a)
    Loading static libraries is not supported in this configuration.
    Try using a dynamic library instead.

    when doing stack build --ghc-options='-fPIC -lpgport -lpgcommon' :aws-sync with

          - -threaded
          - -rtsopts
          - -with-rtsopts=-N
        ld-options: -static
          - ./lib/gmp-6.1.2/.libs
          - ./lib/postgres/src/interfaces/libpq
          - ./lib/postgres/src/common
          - ./lib/postgres/src/port
    Kirill Zaborsky
    @hovind the easiest way to get a proper static build probably is e.g. Stack uses it for its static builds
    @qrilka Thanks, will check it out!
    Alexander Korablev
    @hovind are you succeeded with static libraries?
    Using static-haskell-nix I ended up getting blocked on nh2/static-haskell-nix#22, because I need libpq. There is a workaround, but my case is not that pressing, so I'll wait for upstream. nh2/static-haskell-nix#62 if you want to follow the issue which is blocked upstream by
    static-haskell-nix was quite plug-and-play except for upstream issues, @nh2 has been doing tremendous work.
    Matthieu Coudron
    Hi, I hit the issue "You cannot have packages and a shell-file filled at the same time in your nix-shell configuration." with stack 2.3.1 and this stack.yaml
    resolver: lts-13.19 nix: enable: true shell-file: shell.nix
    there is no packages defined anywhere so I wonder why the warning. There is no package.yaml either.
    Kirill Zaborsky
    @teto there is a possibility that packages are defined in your .stack/config.yaml
    also verbose log of Stack could shine some light maybe (but not sure in this case)
    Matthieu Coudron
    @qrilka how can I get verbose logs ? I've tried several flags from stack --help without success
    Paolo G. Giarrusso
    doesn’t stack take --verbose? but flag order might make a difference (I forget)
    Paolo G. Giarrusso
    Yeah, it's --verbose