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

Post-multilibs checklist #5660

Open
21 of 31 tasks
fgaz opened this issue Nov 4, 2018 · 30 comments
Open
21 of 31 tasks

Post-multilibs checklist #5660

fgaz opened this issue Nov 4, 2018 · 30 comments

Comments

@fgaz
Copy link
Member

fgaz commented Nov 4, 2018

#5526 (multiple public libraries) is in, but there are still a few things to add and polish

Visibility enforcement

cabal-install integration

Tests

Documentation

Bugfixes

Ecosystem changes

@phadej
Copy link
Collaborator

phadej commented Nov 25, 2018

I mark this as high priority as 3.0 cannot be released before Add a visibility field to sublibraries is done.

ping @23Skidoo @hvr

@phadej
Copy link
Collaborator

phadej commented Nov 25, 2018

Should solver be able to flip flags based on visible field? I think it should, but I don't know if it will make implementation tricky.

I don't know a good motivation, maybe pkgA:foo is visible, only if pkgB:bar is available, and author of pkgA.

e.g. pkgA.cabal:

cabal-version: 3.0
name: pkgA
...

library
   -- available always
  build-depends: foo

flag foo
  description: Provide pkgA:foo
  manual: False
  default: True

library foo
  -- this is contrived example, but ...
  -- also it's somewhat fragile, as there isn't a complement constraint; but it should work
  if foo
    visible: True
    build-depends: pkgB:bar

 -- if not pkgB:bar, there's still some stuff to be used by pkgA

@phadej
Copy link
Collaborator

phadej commented Nov 25, 2018

we will need MIN_VERSION_pkgB:foo kind of thing. No idea how the name should be generated though. Maybe double underscore: MIN_VERSION_pkgB__foo? as there cannot be package pkgB--foo?

@phadej
Copy link
Collaborator

phadej commented Nov 25, 2018

Should visibility be recorded into InstalledInfo. Then ./Setup.hs will be able to fail if you try to "manually" use a internal library which was registered as non-visible.

Note: this change would need GHC support (as package database is ghc-pkg business), so this makes things tricky. (practically limiting multilibs for ghc-8.8+)

@fgaz
Copy link
Member Author

fgaz commented Nov 26, 2018

re IPI: yeah, I came to the same conclusion but didn't know how to go at it :-/

Is it just a matter of updating the cabal submodule in the ghc repo?

@phadej
Copy link
Collaborator

phadej commented Nov 26, 2018

@fgaz essentially yes.

@23Skidoo 23Skidoo modified the milestones: 3.0, 3.0.1.0 Oct 16, 2019
@phadej
Copy link
Collaborator

phadej commented Nov 28, 2019

I'm chaging the milestone to 3.2.

@fgaz are you confident you can do this by the mid December (only two weeks!), or should we be waiting this only for 3.4?

@phadej phadej modified the milestones: 3.0.1.0, 3.2 Nov 28, 2019
@phadej
Copy link
Collaborator

phadej commented Dec 10, 2019

Moving to 3.4

@phadej phadej modified the milestones: 3.2, 3.4 Dec 10, 2019
m-renaud added a commit to m-renaud/cabal that referenced this issue Apr 6, 2020
The current output when pretty-printing a Dependency is to unconditionally
include :{<sublibs>}, even when sub-libs is the singleton LMainLibName. This to
begin with is an experimental syntax (haskell#5660) and issues a warning if
cabal-version is <3.0. Since 'cabal format' and soon 'cabal init' use
'Dependency -> PrettyField a' this produces contents in the .cabal file which
cannot be parsed for older config versions.

Testing:

- Verified that round-trip tests through parser/pretty pass
- Unit tests for sublibs={} and sublibs={LMainLibName}
@cartazio
Copy link
Contributor

how can this be progressed? :)

@fgaz
Copy link
Member Author

fgaz commented Apr 30, 2020

Hmm actually some of these may be done. Let me update it first

@fgaz
Copy link
Member Author

fgaz commented Jun 18, 2020

@phadej thank you for all the work you've been doing on fixing those bugs, especially #6893!

@phadej
Copy link
Collaborator

phadej commented Jun 23, 2020

@fgaz is anyone working on Handle installed packages and Make the solver multilibs-aware #6039?

If not, I'll stop waiting for them for Cabal-3.4?


Also if you could check what's missing for Also update the cabal spec changelog, which I forgot, I can do that as well if there are missing points.

@fgaz
Copy link
Member Author

fgaz commented Jun 29, 2020

@phadej

is anyone working on Handle installed packages and Make the solver multilibs-aware

not me, maybe @grayjay?
The solver is multilibs-aware now btw (I just checked the box to make it clearer).
The remaining subtask is not super important, because with v2- there's almost always a source package from which visibility can be determined. The only counterexample I can think of is ghc-bundled packages, but those don't have sublibraries.

what's missing for Also update the cabal spec changelog

Well, there isn't any mention of the multilibs feature, despite it being implemented Cabal-side. Would it be ok to add it to the 3.0 changelog or is that frozen and the 3.4 one should be used?

@fgaz
Copy link
Member Author

fgaz commented Jun 29, 2020

The only counterexample I can think of is ghc-bundled packages

Duh, there's also distros' packages :-/
Does anyone use those in combination with cabal-install v2- though? I can only think of nix

@phadej
Copy link
Collaborator

phadej commented Jun 29, 2020

The remaining subtask is not super important, because with v2- there's almost always a source package from which visibility can be determined. The only counterexample I can think of is ghc-bundled packages, but those don't have sublibraries.

I don't agree. I have heard this argument before, and ended up fixing issues myself because someone run into them. I won't be spending any time arguing whether it's important or not. If it's not done and known issue, the feature is not ready.

The Nix(pkgs) folks how install packages into global package database will run into this issue.

@grayjay
Copy link
Collaborator

grayjay commented Jul 6, 2020

I haven't had time to look into handling installed packages.

donsbot added a commit to donsbot/cabal that referenced this issue Mar 1, 2022
For some projects (e.g. glean) that make wide use of colon specifiers or
visibility, we get hundreds (thousands) of duplicating warnings about
these language features, spamming our builds.

Flatten this warning into a single instance per parse, and a count of
others.

Example:
```
Warning: glean.cabal:1674:15: colon specifier is experimental feature (issue
Warning: glean.cabal:1625:24: visibility is experimental feature (issue haskell#5660)
(and 32 more occurrences)
```

Test plan:
- try on glean.cabal from https://github.com/facebookincubator/Glean and
  see it working as above
- cabal test all
donsbot added a commit to donsbot/cabal that referenced this issue Mar 2, 2022
For some projects (e.g. glean) that make wide use of colon specifiers or
visibility, we get hundreds (thousands) of duplicating warnings about
these language features, spamming our builds.

Flatten this warning into a single instance per parse, and a count of
others.

Example:
```
Warning: glean.cabal:1674:15: colon specifier is experimental feature (issue
Warning: glean.cabal:1625:24: visibility is experimental feature (issue haskell#5660)
(and 32 more occurrences)
```

With -v1 (or below), flattening occurs. At -v2 or above, all instances are shown.

Test plan:
- try on glean.cabal from https://github.com/facebookincubator/Glean and
  see it working as above
- cabal test all
jneira pushed a commit to donsbot/cabal that referenced this issue Mar 4, 2022
For some projects (e.g. glean) that make wide use of colon specifiers or
visibility, we get hundreds (thousands) of duplicating warnings about
these language features, spamming our builds.

Flatten this warning into a single instance per parse, and a count of
others.

Example:
```
Warning: glean.cabal:1674:15: colon specifier is experimental feature (issue
Warning: glean.cabal:1625:24: visibility is experimental feature (issue haskell#5660)
(and 32 more occurrences)
```

With -v1 (or below), flattening occurs. At -v2 or above, all instances are shown.

Test plan:
- try on glean.cabal from https://github.com/facebookincubator/Glean and
  see it working as above
- cabal test all
Kleidukos pushed a commit to Kleidukos/cabal that referenced this issue Mar 30, 2022
For some projects (e.g. glean) that make wide use of colon specifiers or
visibility, we get hundreds (thousands) of duplicating warnings about
these language features, spamming our builds.

Flatten this warning into a single instance per parse, and a count of
others.

Example:
```
Warning: glean.cabal:1674:15: colon specifier is experimental feature (issue
Warning: glean.cabal:1625:24: visibility is experimental feature (issue haskell#5660)
(and 32 more occurrences)
```

With -v1 (or below), flattening occurs. At -v2 or above, all instances are shown.

Test plan:
- try on glean.cabal from https://github.com/facebookincubator/Glean and
  see it working as above
- cabal test all
andreabedini pushed a commit to andreabedini/cabal that referenced this issue May 5, 2022
For some projects (e.g. glean) that make wide use of colon specifiers or
visibility, we get hundreds (thousands) of duplicating warnings about
these language features, spamming our builds.

Flatten this warning into a single instance per parse, and a count of
others.

Example:
```
Warning: glean.cabal:1674:15: colon specifier is experimental feature (issue
Warning: glean.cabal:1625:24: visibility is experimental feature (issue haskell#5660)
(and 32 more occurrences)
```

With -v1 (or below), flattening occurs. At -v2 or above, all instances are shown.

Test plan:
- try on glean.cabal from https://github.com/facebookincubator/Glean and
  see it working as above
- cabal test all
@Mikolaj Mikolaj modified the milestones: Considered for 3.8, 3.9 Jun 3, 2022
@Mikolaj Mikolaj added this to To do in Cabal 3.10 via automation Jul 14, 2022
@kokobd
Copy link
Collaborator

kokobd commented Mar 14, 2023

Is this still being worked on?

@fgaz
Copy link
Member Author

fgaz commented Mar 14, 2023

@kokobd yes... when contributors have the time. Missing items are mostly nice-to-haves and edge cases though. The ongoing stuff is:

Help is appreciated of course!

@gbaz gbaz removed this from To do in Cabal 3.10 Jun 8, 2023
@gbaz gbaz added this to To Do in Cabal 3.12 via automation Jun 8, 2023
@ulysses4ever
Copy link
Collaborator

Another item on that list in the OP, perhaps:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests