What is the best/correct practice to specify version within your source code tree?
What I want is, for instance, to put VERSION file in the top level of the source tree and get the "version" function to read it.
There is a version section in the cabal file. Is it possible to read it from my source by "help" or "version" functions?
What is the correct practice of specifying the version in one place and making it available globaly?
P.S. Are there any functions in the Cabal library that allow you to pull any section from the cabal file and present it in your source? Then I could simply pull the version section from the cabal file.
-- UPDATE --
Thank you Thomas for an nice piece of knowledge about the Pathes_x module.
Just wanted to add that, apparently, I don't need to put anything into my cabal file. Everything just works without it. All I needed was to import the Pathes_X as you sugested.
Also, I needed to import Data.Version to get the showVersion function to properly format/print the Version data type. So at the end I get something like this:
import Paths_kvman
import Data.Version
runVersion _ = putStrLn ("Version: " ++ (showVersion version))
Now, all I need is to change the version number in the cabal file to propagade it all over my source. Exactly what I needed. Thanks.
Cabal automatically generates a module for each package named Paths_packagename. Just import this package and look at the version value it exports.
Edit: For example:
module Data.Blah where
import Paths_t
func :: IO ()
func = print version
And an example run:
> func
Version {versionBranch = [0,1], versionTags = []}
Be sure to put Paths_packagename in your Other-Modules section of the cabal file.
Best practice is to put the version number in your cabal file, as you have already noted.
I am not aware of any good practices by which you can maintain a single point of truth about the version, yet make the number available both to cabal and to your application.
I would recommend a single file Version.hs in the sources with these contents:
module Version
where
version :: String
version = "3.14159"
You could then, if you wished, use some kind of script to update the cabal file with this number, but I don't know how to do this from within cabal itself.
This strategy will work only for application packages; if you are building a library, you'll need to give some thought to where in the namespace of hierarchical modules your Version.hs will go.
On the whole, I suspect the game is not worth the candle.
P.S. The version number should be immutable, so you want a value, not a function.
Related
I have a project with a a library in a few directories. The cabal file is produced with hpack and looks ok. The project builds with cabal build and the main can be run with cabal run xx.
Using repl in vscode, I get occasionally
Could not load module ‘GIS.Subdivisions’
It is a member of the hidden package ‘CatCoreConcepts-0.2’.
Perhaps you need to add ‘CatCoreConcepts’ to the build-depends in your .cabal file.
The package is, of courese, listed in the dependencies. The error is not always occuring and I assume it is a probem with some data cached in the vscode Haskell HLS plugin. Is there a simple way to clean the cache of the plugin? Restart HLS and Developer: reload window in vscode is not having any effect.
I have had the problem where VSCode thinks modules are hidden. Many answers on SO, such as this one. Possible solution, which hopefully helps,
ghc-pkg expose CatCoreConcepts
This is not an answer to the main question, but to some OP comments.
I'd say cabal documentation is good (but lengthy).
A brief summary as I understand (not official documentation)
A Package is a set of components
A component is a set of modules (haskell files)
Module-name and file-name must be equal except for entrypoints (see below)
Components can be classified in two groups:
runnables: tests, benchmarks and executables
runnables must have a unique main function called the entrypoint
In the cabal file, you can use keywords executable, test-suite and benchmark for defining runnables
Within each runnable section in the cabal file there must be a field main-is pointing to the file with the entrypoint
The file-name of the entrypoint can be whatever but the module name must be Main.
Notice that runnable components can have multiple modules (haskell files). For example you can have a test suit consisting in a file with auxiliar functions and other file with the main function. Both files conform a component (a test-suite in this case)
non-runnables: libraries
In the cabal file, you can use keywords library for defining non-runnable component
For libraries you must specify the modules which are exposed with the exposed-modules keyword.
Runnable components can import non-runnable ones even if they are defined in the same package. But viceversa is not true.
As a good practice, each component should be separated in a different folder. Some libraries expect naming convention. For example: tests to be in a folder with the same name and with test_XXXX.hs format (this is regular across programing languages, not only Haskell)
When libraries are separated in folders the field hs-source-dirs must be specified to point to the folder with the haskell files
(the name runnable is not part of the official docs, but is the way I understand)
stack works pretty much the same as cabal since the former is just a different front-end for the later. So aside from different keywords and yaml format, all of the above can be applied to stack (notice that cabal updates more often than stack, therefore some features supported by cabal can be missing in stack.)
If you find this useful, I think I am opening an issue to the cabal docs to include it.
The Haskell project I am working on generates code(and tests for it) that is intended to be used as an independent Haskell library. I want to wrap it in a cabal project, so it can be included as a dependency.
I searched for a library interface for the cabal, so I can create a cabal project at a given directory by calling some functions, but found none.
I could, of course, just run bash commands from Haskell, but it looks ugly to me.
Is there any tool that will solve my problem in a nice way?
You want the Cabal package. You can parse an existing cabal file, change stuff in the data structures, and regenerate the text representation.
Edit in answer to comment:
I don't know of any tutorials. The links I gave are for the Haddock docs, and the mapping between data types and Cabal file text is pretty straightforward. So you should probably start by writing the code to produce a PackageDescription value and then call writePackageDescription on it.
Note the existence of emptyPackageDescription, which lets you just specify the fields you want.
(Removed link to pretty printer class because PackageDescription isn't a member.)
I am pretty new to Haskell as well as stack.
import Data.Set
import Data.Stack
The statements above trigger compilation error: Could not find module 'Data.Set'. Perhaps you meant 'Data.Int'. I tried to google and found nothing similar.
Hence, my question is: do I need to specify external dependencies manually or just my stack build command somewhy fails to grab appropriate modules from somewhat cache or repository?
In case I have to specify my dependencies manually, should I prefer .cabal or .yaml? What's the correct way to deal with versioning?
[Do] I need to specify external dependencies manually [...]?
Yes.
Since you are using Stack, it is easy to specify the dependent packages you import in your code. Depend on your Stack version, the default configuration might be a little bit different:
If you created your project with the latest version of Stack, you will see package.yaml in the root of your project (hpack is used in this case to specify the configurations). You need to add package dependencies there, e.g., containers for Data.Set. Here's an example of a dependencies section in one of my projects:
dependencies:
- base >= 4.7 && < 5
- containers
- time
- network
- bytestring
If you are using an older version of stack and do not see package.yaml, you need to edit your-project-name.cabal to add the dependencies. Here's the complete document telling you how to do it: https://docs.haskellstack.org/en/stable/GUIDE/#adding-dependencies
Personally, I prefer the new system with hpack (package.yaml). Basically, it is simpler, and it saves you time declaring all modules you have (not about dependency). If you have package.yaml, do not edit .cabal, which is automatically generated by hpack.
I want to enhance flycheck-haskell's support for auto-configuring flycheck from your .cabal file.
To do this autoconfiguration, flycheck uses a helper file whose original strategy was to read the .cabal file and use flattenPackageDescription. This was simple, but does not respect conditional expressions, which can cause problems with, e.g. not needing bytestring-builder when using newer version of the bytestring package.
The appropriate interface to use would seem to be finalizePackageDescription. This does work...but its type signature changed between 1.20 and 1.22---now, instead of taking a CompilerId, it now takes a CompilerInfo. Yet I would like to provide consistent support across this API change.
While the solution for this is generally to use CPP macros, those macros are provided by Cabal itself, and flycheck is simply invoking the helper file with runhaskell, so we don't have access to them.
The only option I can think of would be to create another helper to first get the Cabal version information, and then construct appropriate CPP settings for our runhaskell invocation so we can do things that way. That should work, but seems like a hack.
So I'm here looking for other options that would allow me to support both versions of the interface, without having to resort to CPP.
The code in question is a call to Distribution.PackageDescription.Configuration.finalizePackageDescription, like so:
case finalizePackageDescription [] (const True) buildPlatform buildCompilerId [] genericDesc' of
Left e -> putStrLn $ "Issue with package configuration\n" ++ show e
Right (pkgDesc, _) -> print (dumpPackageDescription pkgDesc cabalFile)
The problem is that the fourth parameter, buildCompilerId changed type from CompilerId to CompilerInfo.
What I have implemented---though I would be happy to consider a more self-contained option---is a helper that spits out -DuseCompilerInfo (as an s-expr, since we're dealing with Emacs) if it's a sufficiently recent version of Cabal:
import Data.Version (Version (Version))
import Distribution.Simple.Utils (cabalVersion)
main :: IO ()
main =
putStrLn $ if cabalVersion >= Version [1,22] []
then "(\"-DuseCompilerInfo\")"
else "()"
The original helper is then run with the flag, and conditionally imports the new structures, as well as having the following conditional code just before the case statement above:
#ifdef useCompilerInfo
buildCompilerId = unknownCompilerInfo (CompilerId buildCompilerFlavor compilerVersion) NoAbiTag
#else
buildCompilerId = CompilerId buildCompilerFlavor compilerVersion
#endif
It's not beautiful, but it works.
How do I find the source of the code I am importing. Like if I do
λ <Prelude>: import Graphics.EasyPlot
λ <Prelude Graphics.EasyPlot>:
How do I find that code. I do not mean an online copy of the code (Google is very good at indexing Hackage by that) but where it is on my system that I can edit. The reason is that it is a bit buggy, and I want to try and fix it. (I might submit a patch, but I just want to fix it for my own use first.)
As #ThomasDuBuisson mentioned, you many not necessarily find that on your system. One thing which I generally do is fetch it using cabal:
cabal fetch package-name
It downloads the tarballs of the package. Once you have fetched it, the entire source will be under the path where cabal puts it. In my case, it is (/home/sibi/.cabal/packages/hackage.haskell.org/package-name ). You can then untar and then build it from the cabal file which is already present there.
That being said you should probably using the version control system which the project is using as #bheklilr pointed out.