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

Use recommended method to obtain tool dependencies #52

Merged
merged 1 commit into from Oct 3, 2017

Conversation

Projects
None yet
2 participants
@duog
Contributor

duog commented Oct 2, 2017

Addresses #50 . This is documented as the recommended way to obtain tool
dependencies in
https://hackage.haskell.org/package/Cabal-2.0.0.2/docs/Distribution-Simple-BuildToolDepends.html

I've tested this by running

stackage-curator create-plan --target nightly-2017-10-03 --plan-file test.yaml

with and without this patch, and observing that the language-c/description/tools key is empty without the patch, and contains happy and alex with the patch.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 3, 2017

Member

I'm slightly nervous about this, since this is following Cabal's new definition (as of 2.0) for build tool dependencies, which is different from what Stack does (look at all of the package in a snapshot). I think overall this will work out fine though, since a failure here will result in a failed snapshot.

Anyway: can you add a note to the changelog?

Member

snoyberg commented Oct 3, 2017

I'm slightly nervous about this, since this is following Cabal's new definition (as of 2.0) for build tool dependencies, which is different from what Stack does (look at all of the package in a snapshot). I think overall this will work out fine though, since a failure here will result in a failed snapshot.

Anyway: can you add a note to the changelog?

@duog

This comment has been minimized.

Show comment
Hide comment
@duog

duog Oct 3, 2017

Contributor

I will add a note.

I am quite confused by this, as it looks like a regression to me. Are your stackage-curator installs/stackage-curator make-bundles working with nightlys on or after 2017-07-31? They're failing for me due to this.
I was surprised that stack works(don't know why, stack seems to pretty much always just work :) ):

$ stack --resolver nightly-2017-07-31 build language-c

as I assumed it used the tools field, but it looks like it does something equivalent to getAllToolDependencies at runtime:
https://github.com/commercialhaskell/stack/blob/93f386300d56e10dfee2e61c79006b944a8e70f2/src/Stack/Package.hs#L598

Contributor

duog commented Oct 3, 2017

I will add a note.

I am quite confused by this, as it looks like a regression to me. Are your stackage-curator installs/stackage-curator make-bundles working with nightlys on or after 2017-07-31? They're failing for me due to this.
I was surprised that stack works(don't know why, stack seems to pretty much always just work :) ):

$ stack --resolver nightly-2017-07-31 build language-c

as I assumed it used the tools field, but it looks like it does something equivalent to getAllToolDependencies at runtime:
https://github.com/commercialhaskell/stack/blob/93f386300d56e10dfee2e61c79006b944a8e70f2/src/Stack/Package.hs#L598

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 3, 2017

Member
Member

snoyberg commented Oct 3, 2017

@duog

This comment has been minimized.

Show comment
Hide comment
@duog

duog Oct 3, 2017

Contributor

in nightly-2017-07-25 language-c has entries for alex and happy in it's tools entry. In nightly-2017-07-31(first nightly with ghc-8.2.1 and Cabal-2) it does not. when I run

stackage-curator install --build-plan nightly-2017-07-31.yaml work

language-c fails due to missing happy.

Contributor

duog commented Oct 3, 2017

in nightly-2017-07-25 language-c has entries for alex and happy in it's tools entry. In nightly-2017-07-31(first nightly with ghc-8.2.1 and Cabal-2) it does not. when I run

stackage-curator install --build-plan nightly-2017-07-31.yaml work

language-c fails due to missing happy.

@duog

This comment has been minimized.

Show comment
Hide comment
@duog

duog Oct 3, 2017

Contributor

https://github.com/duog/build-stackage has my script, it's using a fork of stackage-curator that includes this commit, so it would require a bit of mucking about with the submodule to reproduce.

Contributor

duog commented Oct 3, 2017

https://github.com/duog/build-stackage has my script, it's using a fork of stackage-curator that includes this commit, so it would require a bit of mucking about with the submodule to reproduce.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Oct 3, 2017

Member

alex and happy probably already built successfully, and using a clean build may trigger the bug on our server.

Member

snoyberg commented Oct 3, 2017

alex and happy probably already built successfully, and using a clean build may trigger the bug on our server.

@snoyberg snoyberg merged commit 19e53f2 into fpco:master Oct 3, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment