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
Check PVP import compliance with 'cabal check' #1703
Comments
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:
|
Am 28.02.2014 21:14, schrieb Johan Tibell:
How can I find out line numbers? Cabal gives me a PackageDescription |
It might be difficult. How about using the section name instead?
|
Am 28.02.2014 22:26, schrieb Johan Tibell:
I am using flattenPackageDescription in order to get rid of the |
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.
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. |
Am 01.03.2014 16:55, schrieb Tobias Florek:
I have seen this error myself, but don't know about its origin. At |
I've seen this error too and it was related to trying to use some cabal operation on a sources of some cabal package after installing a new version of cabal while the package was already cabal-configured.
You will get the above mentioned error (though the versions will be 1.18.0.2 and 1.19) Running "cabal configure" for package Foo again fixed this issue in my case. My understanding is that new Cabal tried to use cached LocalBuildInfo for Foo package (stored in dist/setup-config or something like that) and format (and Cabal version reference) has changed thus the error. Hope this helps
|
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. |
Am 02.03.2014 11:31, schrieb Tobias Florek:
If you run check-pvp with the --include-all option, the package |
Has there been any progress on this one since the last comment? |
Am 26.04.2014 13:16, schrieb Herbert Valerio Riedel:
Not really. The checks are simple and implemented, however the |
@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 |
Am 26.04.2014 17:17, schrieb Herbert Valerio Riedel:
I could add an "--exclude-all" option analogously to the "--include-all" |
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.) |
In the libraries@haskell.org mailing list from time to time the issue of package versioning policy compliance arises. There is a recent round starting with Data.Bits.zero. 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
or
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:
I think that version ranges like
>=0.5 && <1.0
must always be warned about,and ranges like
>=0.5 && <0.5.0.1
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.The text was updated successfully, but these errors were encountered: