commercialhaskell/stackage

Haskell Stackage.org

Eric Torreborre

@etorreborre

I must still be doing something wrong

Eric Torreborre

@etorreborre

I fixed it with export LIBRARY_PATH=/usr/local/opt:$LIBRARY_PATH

Michael Snoyman

@snoyberg

@etorreborre nice! I wonder if we can document this somewhere, or maybe even add a hint to Stack when it notices this situation

Eric Torreborre

@etorreborre

I appear to be the only one in my neighbourhood to have this issue. This might be unique to my configuration?

Michael Snoyman

@snoyberg

That's certainly possible. It could be that I hit this issue in the distant past and already patched it for myself.

Adam Bergmark

@adambergmark_twitter

i’m pretty sure i haven’t had to fix it on my machine

Michał J. Gajda

@mgajda

Hi Stackagers, I see a few bugs in latest json-autotype that appear in Stack builds only:

Issue of filesystem access in Stackage builds. Is /tmp accessible then?
commercialhaskell/stackage#4185

Heisenbug when executing stack runghc on CI:

Test suite failure for package json-autotype-3.0.0
 json-autotype-examples:  exited with: ExitFailure 1
Full log available at /builds/migamake/json-autotype/.stack-work/logs/json-autotype-3.0.0-test.log

 stack: WARNING! Expecting stack options comment at line 1, column 1
 stack: WARNING! Missing or unusable stack options specification
 stack: WARNING! Using runghc without any additional stack options
 Invalid argument `run'
 Error executing interpreter command: stack run -- runghc -- examples/json-schema/fstab.json --outputFilename output/Fstab.hs

https://gitlab.com/migamake/json-autotype/-/jobs/126570099
Here is the code that implements nested call to Stack:

runHaskellModule :: [String] -> IO ExitCode
runHaskellModule arguments = do
 maybeStack <- System.Environment.lookupEnv "STACK_EXEC"
 maybeCabal <- System.Environment.lookupEnv "CABAL_SANDBOX_CONFIG"
 let execPrefix | Just stackExec <- maybeStack = [stackExec, "runghc"]
                | Just _         <- maybeCabal = ["cabal",   "exec", "runghc"]
                | otherwise                    = ["runghc"]
 putStrLn $ "Running Haskell module: " ++ show execPrefix ++ show arguments
 system $ Prelude.unwords $ execPrefix ++ arguments

https://github.com/mgajda/json-autotype/blob/master/json-autotype/src/Data/Aeson/AutoType/CodeGen/Haskell.hs

Can you please lend me a hand?

Michał J. Gajda

@mgajda

@mihaimaruseac Please?

Mihai Maruseac

@mihaimaruseac

I didn't investigat, just disabled the test from compiling and running

I'll take a look later

Michał J. Gajda

@mgajda

@mihaimaruseac Thanks in advance. It may be a bug in the way I detect stack environment or bug in the way stack runs nested. Either way, I would need your guidance as to how to improve it, since detection of nested stack environment is a bit of a riddle to me.

Can you tell anything about whether /tmp is available on Stackage CI?

Mihai Maruseac

@mihaimaruseac

it should be available

Michał J. Gajda

@mgajda

I thought that normal policy when building and testing with Stack is to use .stack-work, but can use /tmp instead

Is there a way to detect the right directory?

Adam Bergmark

@adambergmark_twitter

to clarify, the stackage build server builds with cabal-install, not stack. This will change with the new stackage-curator which is in development

Michał J. Gajda

@mgajda

@adambergmark_twitter Understood. This makes it even more confusing because it builds in cabal 1.x, stack, and pier environment as well.
Maybe there should be Paths_json_autotype.getTestOutputDir and Paths_json_autotype.howToExecNestedGhc entries to normalize it?

I can raise the same issue in the Cabal repo.

Travis CI across all compiler and Cabal versions does not reproduce this bug:
https://travis-ci.org/mgajda/json-autotype

Mihai Maruseac

@mihaimaruseac

That's really interesting

Michał J. Gajda

@mgajda

I see that stack run is unsupported by stack version 78762f94d371e68aaa0dd8071bb9b97c3d7760de. I can move to stack runghc instead, if there is reasonable guarantee that it will work.

Mihai Maruseac

@mihaimaruseac

I'd try with stack exec -- your command

Dan Burton

@DanBurton

to clarify, the stackage build server builds with cabal-install,

To further clarify, the stackage build server builds with runghc Setup configure, runghc Setup build, etc. 100% of the time, Setup.hs is cabal's defaultMain or some other use of Cabal, but in theory, it could be anything.

Domen Kožar

@domenkozar

Are there any objections moving forward bumping quickcheck/hspec/servant?

Dan Burton

@DanBurton

@domenkozar I am in favor of this. I'll push it through next week if it hasn't been done already.

Domen Kožar

@domenkozar

Thanks!

Domen Kožar

@domenkozar

btw, not all dependencies of packages are stackage anymore. Is that known?

for example, cabal-install depends on resolv, which is not in TLS-13.1

Adam Bergmark

@adambergmark_twitter

that is a conditional dependency, the native-dns flag is disabled

Domen Kožar

@domenkozar

ah makes sense :)

Domen Kožar

@domenkozar

actually I find that a bit confusing, what if someone enables that flag (as it's default ON)

then stackage kind of falls short

Dan Burton

@DanBurton

Stackage snapshots include the flags we used for the build. So if stack users are using a given snapshot, unless they explicitly choose to enable it, that flag will be disabled by default.

I agree that if users enable the flag, they may get a bad and confusing experience, but this is, at least, not something that a beginner would think to do.

tl;dr stack build cabal-install should work correctly for people that are sticking to stackage defaults.

Dan Burton

@DanBurton

Here's a snippet from the latest snapshot file, to be specific about where this info is:

  cabal-install:
    users: []
    constraints:
      benches: expect-success
      library-profiling: true
      flags:
        native-dns: false

Or, if you're consuming the new format:
https://github.com/commercialhaskell/stackage-snapshots/blob/master/nightly/2018/12/31.yaml#L40

One more thought: we can always add resolv and other missing deps back into the build plans anyways. Assuming it is compatible and all. Not sure how difficult it would be to detect which conditional dependencies we could harmlessly include automatically, but we can for sure include them on a case-by-case basis as needs arise, such as this.

Michael Snoyman

@snoyberg

I've opened up a PR to remove the upper bound on haskell-src-exts. It cause a bunch of packages to get dropped, anyone interested may wish to check out: commercialhaskell/stackage#4330

hjoly2003

@hjoly2003

Hi, I'm trying to install the package unix with the following command:

hjoly2003

@hjoly2003

Hi, I can't install the package unix with with the following command:
stack build --copy-compiler-tool unix.
When I tried this, nothing happened.

I have Mac Sierra and I would expect the unix-2.7.2.2 version to be installed. My GHC version is 8.6.4.
Thanks in advance.

Michael Snoyman

@snoyberg

--copy-compiler-tool only applies to executables, while unix is a library. Also, unix ships with GHC itself and doesn't need to be built. In other words: your command is a no-op, which is why nothing happened

Domen Kožar

@domenkozar

Excited for LTS-14, hope it's around the corner :)

Adam Bergmark

@adambergmark_twitter

build is in progress, last i heard

we’re building it with the new curator so some issues may pop up

Chris Dornan

@cdornan

indeed -- unless there is some major surprise the next release should be LTS-14, but some minor surprises might delay it until next w/e

Chris Dornan

@cdornan

it is out: https://www.stackage.org/lts-14.0

Shao Cheng

@TerrorJack

It seems ghc boot libs like base disappeared in lts-14.1?

Adam Bergmark

@adambergmark_twitter

thanks for the report. I’m not sure if that is a known issue with the new build tool. I copied the question to our other chat

Michael Snoyman

@snoyberg

@TerrorJack can you clarify what you mean by that? Where do you see base has disappeared? It's still present on stackage.org, and is not intended to be present in the snapshot files

Shao Cheng

@TerrorJack

@snoyberg Strange. When I reported earlier, those libs were not present in 14.1, and the diff between 14.1 and 14.0 had a lot of disappeared libs. Now it's normal

Where communities thrive

People

Repo info

Activity