Skip to content
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

Do not remove sublibrary information when adding pvp-bounds #5309

Merged
merged 1 commit into from
Jun 8, 2020
Merged

Do not remove sublibrary information when adding pvp-bounds #5309

merged 1 commit into from
Jun 8, 2020

Conversation

dzhus
Copy link
Contributor

@dzhus dzhus commented Jun 3, 2020

This fixes stack sdist broken when using pvp-bounds, see
#5289. This is a
regression after #5156.

When using pvp-bounds we pretty-print an updated package description
back to .cabal file. If a set of sublibraries used in a dependency is
empty (from cabal-the-library perspective) then instance Pretty Dependency from
https://hackage.haskell.org/package/Cabal-3.0.0.0/docs/src/Distribution.Types.Dependency.html#line-58
will just print an empty set there:

build-depends: vector : {} <0.13

This leads to the following error when using stack sdist:

- 46:16:
unexpected Sublibrary dependency syntax used. To use this syntax the package needs to specify at least 'cabal-version: 3.0'. Alternatively, if you are depending on an internal library, you can write directly the library name as it were a package.
expecting space

What we want instead is to use the same sublibrary set as the original
dep. I suspect most of the time it's just [LMainLibName], which
thanks to instance Pretty Dependency omits the {} in the
dependency line and is hence (hopefully) compatible with whatever
cabal-version the original .cabal file used.

Note: Documentation fixes for https://docs.haskellstack.org/en/stable/ should target the "stable" branch, not master.

Please include the following checklist in your PR:

  • Any changes that could be relevant to users have been recorded in the ChangeLog.md
  • The documentation has been updated, if necessary.

I tested this manually doing a stack sdist in a package which has pvp-bounds enabled.

Copy link
Contributor

@snoyberg snoyberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks! One request: can you rebase this to target the stable branch instead?

This fixes `stack sdist` broken when using pvp-bounds, see
#5289. This is a
regression after #5156.

When using pvp-bounds we pretty-print an updated package description
back to .cabal file. If a set of sublibraries used in a dependency is
empty (from cabal-the-library perspective) then `instance Pretty
Dependency` from
https://hackage.haskell.org/package/Cabal-3.0.0.0/docs/src/Distribution.Types.Dependency.html#line-58
will just print an empty set there:

    build-depends: vector : {} <0.13

This leads to the following error when using `stack sdist`:

    - 46:16:
    unexpected Sublibrary dependency syntax used. To use this syntax the package needs to specify at least 'cabal-version: 3.0'. Alternatively, if you are depending on an internal library, you can write directly the library name as it were a package.
    expecting space

What we want instead is to use the same sublibrary set as the original
dep. I suspect most of the time it's just `[LMainLibName]`, which
thanks to `instance Pretty Dependency` omits the `{}` in the
dependency line and is hence (hopefully) compatible with whatever
`cabal-version` the original .cabal file used.
@dzhus dzhus changed the base branch from master to stable June 8, 2020 08:53
@dzhus dzhus requested a review from snoyberg June 8, 2020 09:08
Copy link
Contributor

@snoyberg snoyberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@snoyberg snoyberg merged commit d505c86 into commercialhaskell:stable Jun 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants