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

Prevent dependency on private library #5848

Merged
merged 5 commits into from
Jun 25, 2019

Conversation

fgaz
Copy link
Member

@fgaz fgaz commented Jan 16, 2019

This will make Cabal error out when depending on a private library.

It does not give detailed info on which sublibrary is the culprit because that would require changing the dependencySatisfiable and finalizePD return types, and that touches A LOT of the codebase. It can be done later.

/cc @ezyang @phadej

TODO:

  • on older ghcs treat all internal libraries as private and all main libraries as public, instead of "everything is private"
    • even on older older ghcs (<8.2)

Closes #5806

@fgaz fgaz added this to the 3.0 milestone Jan 16, 2019
@fgaz
Copy link
Member Author

fgaz commented Jan 16, 2019

Oops, of course on ghc <8.8 all libraries are private 🤦‍♂️

@fgaz fgaz mentioned this pull request Jan 24, 2019
@fgaz fgaz mentioned this pull request Feb 2, 2019
31 tasks
@fgaz fgaz force-pushed the prevent-dep-on-private-lib branch from af482b4 to 6d5ab50 Compare February 3, 2019 14:38
@fgaz
Copy link
Member Author

fgaz commented Feb 3, 2019

Hmm, this probably requires to add visibility to Basic, so we can turn it into LibraryVisibilityPublic if it's a LMainLibName

@fgaz fgaz force-pushed the prevent-dep-on-private-lib branch 2 times, most recently from 2d0bfac to 86daec5 Compare February 4, 2019 17:01
@fgaz fgaz requested review from phadej, ezyang, 23Skidoo and hvr February 4, 2019 17:02
@fgaz
Copy link
Member Author

fgaz commented Feb 4, 2019

This is now complete and reviewable

(Sorry for the mass ping)

Copy link
Collaborator

@phadej phadej left a comment

Choose a reason for hiding this comment

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

It would be nice if we had a test that depending on a private lib fails as expected.

Adding a positive variant is possible only when GHC-8.8 is out, please make an issue about that.

Copy link
Member

@hvr hvr left a comment

Choose a reason for hiding this comment

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

I'm not so sure anymore we should merge this; I'm still discussing this with @fgaz

@phadej
Copy link
Collaborator

phadej commented Mar 3, 2019

@hvr why

I'm not so sure anymore we should merge this;

?

@fgaz
Copy link
Member Author

fgaz commented Mar 4, 2019

@phadej

Concerns about the narrow ghc compatibility. As it is, this patch only allows multilibs on GHC<8.8 and doesn't provide an override. If it did (for example when using --exact-config), then cabal-install could make multilibs work even on older GHCs by getting the visibility info from an IPI-external source.

Also this makes cabal-install fail after build plan construction, which is not pleasant, but the only way to solve that is to make the solver sublibrary-aware.

@23Skidoo
Copy link
Member

23Skidoo commented May 6, 2019

@fgaz @hvr Do you still want this in 3.0?

@phadej
Copy link
Collaborator

phadej commented May 6, 2019

This has priority: high.

But in fact, i'm leaning towards disabling parsing of visibility field (i.e. essentially removing the multiple public libraries feature from public usage), if it won't be finalized in some way.

This is because I simply don't understand all the implications of the choices, and want to error on the safe side.

@23Skidoo
Copy link
Member

23Skidoo commented May 6, 2019

I'm fine with postponing it until 3.2.

@fgaz
Copy link
Member Author

fgaz commented May 7, 2019

I think we can, and in fact should merge this, even if we end up disabling visibility for 3.0, simply because we can relax the constraint later, but the opposite is difficult. As it is, the rest of multilibs is already there, unconstrained.

Now, should we, in another pr, disable it? well...

  • When this pr is merged, the Cabal part will be complete
    • The only missing piece I can think of is the error reporting I mentioned in the OP
  • cabal-install is not multilibs-aware, but IMO this is not so bad. Changing the visibility of a library
    can be treated like changing the visibility of a module for now, like I suggest in this blog post draft
    (see the warnings)
  • The BC problem cannot be solved at the Cabal level, but we can provide an override which can be used by future cabal-install releases
    • This can just be exact-config
      • Easy to implement at the Cabal level, it's just an extra condition
        here
      • I think this requires at least a basic no-deps-on-private-libs check in cabal-install, since we always pass exact-config
    • Or it can be an entirely new flag (--allow-depending-on-private-libs-yes-im-checking-it-externally)
      • Easy-ish to add to Cabal, there should just be a lot of boilerplate since we have to pass it down to dependencySatisfiable (like we do with exact-config)
      • Requires no modifications to cabal-install 3.0
      • Probably the safest option
    • Or we can add the override in later Cabal versions. A minor version, even (if we use a new flag)

TL;DR: +1 for merging, -1 for disabling multilibs, I'm for adding a new flag to allow future cabal-installs to override visibility and expand BC

@23Skidoo
Copy link
Member

23Skidoo commented May 7, 2019

OK, I'll try to review this PR this week. Sorry for being slow.

@fgaz fgaz force-pushed the prevent-dep-on-private-lib branch from 86daec5 to fcbe835 Compare May 7, 2019 16:58
@fgaz
Copy link
Member Author

fgaz commented May 7, 2019

np


Added a negative package test

@hvr
Copy link
Member

hvr commented May 7, 2019

but we can provide an override which can be used by future cabal-install releases

please do! :-)

@fgaz
Copy link
Member Author

fgaz commented May 10, 2019

The test is failing for ghc <=8.0.*

Somehow for those versions sublibraries always appear as public. I'm investigating, but I don't see any clues in the ghc changelog

edit: 8.2 included Cabal 2.0 (the first version with internal libraries and backpack), so it may be that.
edit2: I could just disable public libs for ghc <8.2

fgaz and others added 3 commits June 8, 2019 21:39
ghc-pkg<8.8 cannot read the visibility field, so all libraries were reported
as private, even the main (unnamed) one. This commit forces the
visibility of main libraries to be "public".

This commit can be reverted once we stop supporting GHC<8.8, at the
condition that we keep marking main libraries as public when registering
them.
Related to the previous two commits (preventing dependency on private
libraries and marking main libraries as public)
@fgaz fgaz force-pushed the prevent-dep-on-private-lib branch from f88a8ad to 88ecdd7 Compare June 8, 2019 19:39
@fgaz
Copy link
Member Author

fgaz commented Jun 8, 2019

OK, this should fix the older ghcs. I also added the --allow-depending-on-private-libs flag which can be used by cabal-install later.

Ping @23Skidoo

This is intended to be used by tools like cabal-install so they can add
multilibs-compatibility even to older ghcs
@fgaz fgaz force-pushed the prevent-dep-on-private-lib branch from 88ecdd7 to 3e31042 Compare June 17, 2019 15:18
@fgaz
Copy link
Member Author

fgaz commented Jun 21, 2019

The travis failures are unrelated to this (I did not even modify ResponseFiles.hs).

@23Skidoo can we merge?

@@ -703,6 +707,13 @@ configureOptions showOrParseArgs =
configUseResponseFiles
(\v flags -> flags { configUseResponseFiles = v })
(boolOpt' ([], ["disable-response-files"]) ([], []))

,option "" ["allow-depending-on-private-libs"]
Copy link
Member

Choose a reason for hiding this comment

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

This should be added to filterConfigureFlags as well, though since we don't set it anywhere, it's not a blocker for merging.

@23Skidoo 23Skidoo merged commit 9756b4c into haskell:master Jun 25, 2019
@23Skidoo
Copy link
Member

Merged, thanks!

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

Successfully merging this pull request may close these issues.

RFC: library visibility enforcement
4 participants