The current documentation of cabal shows a sandbox subcommand.
The respective page on github no longer contains the section on sandboxes.
I'm using cabal version 3.2.0.0, but the sandbox subcommand is absent. What is the correct way to manage sandboxes with cabal?
Apparently there's an overhaul going on with the documentation, there's mention of a Nix-style/new-/v2 commands but it's unclear to a noob what's the canonical way of using sandboxes with cabal.
They're no longer needed. The nix-style store does everything sandboxes did, but better. Just use use cabal build (cabal v2-build for pre-3.0 cabal's) and other cabal commands with impunity in a bare, sandbox-free directory.
Related
In the Cabal User Guide it says that Cabal is often compared with autoconf and automake since the command line interface for actually configuring and building packages follows the same steps steps:
./configure --prefix=...
make
make install
compared to
cabal configure --prefix=...
cabal build
cabal install
My understanding is that ./configure uses a config file (produced by autoconf) to adapt the make process to the environment in which it will run and also to check dependencies. So ./configure therefore always have an "input" to conform to. But if cabal configure is not given any arguments what does it do, and why is it necessary before running cabal build?
The cabal configure step does at least two things I know of:
Check that the package description parses OK.
Check that all required dependencies are already installed (and report an error if not).
Basically it's running the constraint solver to decide exactly which packages you're going to build against. (E.g., if you have several versions of ByteString installed, which version are you going to use? Well it might depend on which version the packages you depend on are expecting...)
Also I believe it's possible to supply options at configure time which change exactly which features of the package get built (but I don't have experience with this).
I think originally you had to call configure before you could call build, but I believe now the cabal command-line tool does that step for you automatically in many cases. (E.g., cabal run now seems to automatically reconfigure if the package description file is newer than the configuration DB.)
I recently downloaded the Haskell Platform from the Haskell website. Under the suggestion of the newer answers in this, I blindly ran brew install ghc cabal-install and cabal install cabal cabal-install. Did I install two versions of Haskell on my machine? What should I do to fix any problems?
It doesn't necessarily lead to problems to have multiple versions (I think I have three different versions installed). If you need the disk space uninstall one of the two (instructions for the brew one, for the packaged platform it seems you should be able to use the command sudo uninstall-hs but check it yourself first). If you don't mind the lost disk space, you only have to make sure you have your PATH set up correctly, with the directory containing the ghc binary you want to use in your PATH, before the directory of the other one.
Also, cabal install cabal-install (which you might need to run to update cabal) tends to install cabal in a different place than the platform/brew do, so there, again, you need to make sure your PATH is appropriately set. Normally cabal installs executables in ~/.cabal/bin (local installs) or /usr/local/bin (global installs). The directory containing cabal should go before the others, because an old version of cabal might stick around and you want the new one to be found first.
You probably know this but you can use which ghc and which cabal to check the location of the executable actually being used.
To make things even more complicated, lately it's popular to use Stack, which can also install ghc for you (I find this very convenient, everything is kept in a very controlled environment). So depending on your experience/use case this might be worth looking at as well (but if you just want to try Haskell I recommend you stick with the platform or the brew installation).
The installation instructions at the Stackage web site describe how to use it for one project.
Is there a way how to configure Stackage to be the default for all users and install packages globally available to them?
AFAIK cabal does not support a global config file. But even that won't help by itself because afaict, you can't disable configured remote-repos anyway.
So I see two approaches with obvious drawbacks.
Clean way for new users
Install a /etc/skel/.cabal/config file that will be copied to new user accounts. That won't help with older users though.
Hacky way for all users
Install a global alias (or shell script wrapper) with name cabal that calls cabal --remote-repo=hackage.haskell.org:http://www.stackage.org/lts.
Users can opt out by unaliasing cabal or using the real cabal executable when using a shell script.
Users will be utterly confused though, because cabal will tell users it uses hackage, when in fact it is using stackage.
I would like to work on a project in a cabal sandbox. But instead of using the same remote-repo as my non-sandboxed code (i.e., Hackage), I'd like to point to a different remote repo. I tried creating a cabal.config file in the project directory with a remote-repo line, but it seemed to have no effect; running cabal update after that indicated that Hackage was being downloaded, but not my custom repo.
Is this use case supported, and if so, how do I achieve it?
This is in fact a Cabal bug, I've opened a Github issue about it.
How can I browse Haskell source code preferably without internet connection? Right now I click through hackage search results, click source link and search the source page. There are two problems:
I'm using current version as a proxy of what I have locally
This does not work recursively well (another clicks and searches for next definition)
Usually IDEs let you download sources for any library and open new editor tab with definition. I prefer reading code than documentation, less surprises along the way and I can learn something from them.
So, how can I setup for recursive source searches using Haskell tools or standard GNU tools if necessary? All I know right now is that I can generate ctags for vim but where does cabal store sources?
This is the opinionated workflow I follow to render the documentation with the source link enabled.
$ cd <package-name>
$ cabal sandbox init
$ cabal install --only-dependencies --enable-documentation --haddock-hyperlink-source
$ cabal configure --enable-documentation --haddock-hyperlink-source
$ cabal haddock --hyperlink-source
$ firefox dist/doc/html/<package-name>/index.html
The Source link should be enabled for all packages, including the dependencies, as long as they are installed in the sandbox.
In the particular case of Arch Linux, the distro I use, I try to avoid installing Haskell system packages through pacman because, by default, the documentation is not built with the source link enabled. In Arch Linux you can use ABS and modify the PKGBUILD with the parameters described above. I'm pretty sure something similar could be done in other distros, but have no idea about Windows or Mac OS X.
It's also worth mentioning that you don't need to type those parameters every time you run cabal. You can enable them by default in your .cabal/config
This should work without the sandbox but if you are dealing with more than one Haskell project I strongly recommend to use sandboxes.