Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Check PVP import compliance with 'cabal check' #1703

amigalemming opened this Issue · 16 comments

8 participants


In the mailing list from time to time the issue of package versioning policy compliance arises. There is a recent round starting with My observation is that programmers try to comply to the PVP on the export side, but not at the import side. That is, if you import identifiers unqualified and implicitly, you also must specify tight version bounds. But most packages don't do that. I like to add the following check to cabal check:

If a package is imported like
Build-Depnds: containers >=0.5 && <0.6
then only qualified imports and explicit imports are allowed, e.g.
import qualified Data.Map as Map
import Data.Map (Map)

In contrast, if the module YourModule imports like
import Data.Map as Map
import Data.Map hiding (insert)
then a warning like the following one should be emitted:

"Package imports do not comply with the Package Versioning Policy PVP.
YourModule imports Data.Map inconsistently to the package import of 'containers'.
According to your currently configured package versions you may resolve the problem in three ways:
1. import qualified Data.Map as XYZ
2. import Data.Map (x, y, z)
3. restrict version bounds: containers >=0.5 && <0.5.1"

I think that version ranges like >=0.5 && <1.0 must always be warned about,
and ranges like >=0.5 && < are always safe.

Now I am thinking about an implementation. I need to parse the module import parts, also in the presence of comments, TemplateHaskell and C preprocessor directives. Is this already available? I guess I must not add a dependency on the GHC parser or haskell-src-exts to Cabal. I also need access to currently configured package versions, but this one should exist already.

Then I wonder whether this shall be part of Cabal or cabal-install. So far, cabal check is only available in cabal-install, not in Cabal. I don't know the reason for it, but in order to be least invasive I would start extending the 'check' command of cabal-install.


Try implementing this as a separate tool first. Then we can think about adding this functionality to Cabal.


I prepared a first version of such a tool:


@amigalemming I took it out for a spin. Here's some early user feedback, I hope you don't mind:

  • I have several sections (e.g. library, test suites, and benchmarks) in my Cabal file and I cannot attribute the errors to the sections as the warning don't include line numbers or section names.
  • There are a few too many newlines so the output takes up more than one screen. How about:

    my-file.cabal:6: base: upper bound 5 is too lax
  • The tool failed on files that contain CPP. Perhaps because of haskell-src-ext not checking for the CPP pragma? If it's to hard to get haskell-src-exts to do that, perhaps you could look for the extensions directive in the Cabal file instead?

How can I find out line numbers? Cabal gives me a PackageDescription
without line numbers. :-(

It might be difficult. How about using the section name instead?

library: base: upper bound 5 is too lax
some-test-suite: base: upper bound 5 is too lax

some other feedback re check-pvp (which is a great idea).

i get the following error constantly because i have a recent (not yet released) cabal which i install sandboxed.

check-pvp: user error (You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.9999, now Cabal-1.16.0).)

i have not looked at the source so i don't know whether this is harmful or not (i guess not, because it works as advertised for my small tests). if so, it would be great to suppress that warning.


thanks for your comments. i know why this happens (i am running cabal head and compiled check-pvp with an older cabal library). i was wondering whether this can be mitigated without re-configuring, but it does not seem serious, so i can live with it.


Has there been any progress on this one since the last comment?


@amigalemming would it make sense to add a subset of your checks for starters which do not depend on parsing the files at all for starters? I.e. just perform the sanity checks that make sense even without parsing the import statements (e.g. total omission of bounds, bounds that seem suspicious, like e.g. <= 1.0 or bounds that are overly lax with respect to the currently existing package version in the package index (and maybe suggesting values for the missing/suspicious package bounds like cabal init does)?)

@ttuegel ttuegel added the enhancement label
@ttuegel ttuegel added this to the _|_ milestone
This was referenced

If anyone ever takes a stab at this, see also #465 (point being that this should probably be opt-in via a field in the .cabal file.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.