Cabal Online Ph Download Manual Patch
Jason Ramgel
This introductory guide takes a new Stack user through the typical workflows.This guide will not teach Haskell or involve much code, and it requires no priorexperience with the Haskell packaging system or other build tools. Terms used inthe guide are defined in the glossary.
The primary Stack design point is reproducible builds. If you runstack build today, you should get the same result running stack buildtomorrow. There are some cases that can break that rule (changes in youroperating system configuration, for example), but, overall, Stack follows thisdesign philosophy closely. To make this a simple process, Stack uses curatedpackage sets called snapshots.
Stack has also been designed from the ground up to be user friendly, with anintuitive, discoverable command line interface. For many users, simplydownloading Stack and reading stack --help will be enough to get up andrunning. This guide provides a more gradual tour for users who prefer thatlearning style.
To build your project, Stack uses a project-level configuration file, namedstack.yaml, in the root directory of your project as a sort of blueprint. Thatfile contains a reference to the snapshot (also known as a resolver) whichyour package will be built against.
Finally, Stack is isolated: it will not make changes outside of specificStack directories. Stack-built files generally go in either the Stack rootdirectory or ./.stack-work directories local to each project. TheStack root directory holds packages belonging to snapshots andany Stack-installed versions of GHC. Stack will not tamper with any systemversion of GHC or interfere with packages installed by other build tools, suchas Cabal (the tool).
The documentation dedicated to downloading Stack hasthe most up-to-date information for a variety of operating systems. Instead ofrepeating that content here, please go check out that page and come back herewhen you can successfully run stack --version.
In this guide, an initial $ represents the command line prompt. The prompt maydiffer in the terminal on your operating system. Unless stated otherwise, theworking directory is the project's root directory.
A package is identified by a globally-unique package name, which consistsof one or more alphanumeric words separated by hyphens. To avoid ambiguity,each of these words should contain at least one letter.
We'll call our project helloworld, and we'll use the new-template projecttemplate. This template is used by default, but in our example we will refer toit expressly. Other templates are available. For further information abouttemplates, see the stack templates commanddocumentation.
For this first Stack command, there's quite a bit of initial setup it needs todo (such as downloading the list of packages available upstream), so you'll seea lot of output. Over the course of this guide a lot of the content will beginto make more sense.
After creating the project directory, and obtaining and populating the projecttemplate, Stack will initialise its own project-level configuration. For furtherinformation about setting paramaters to populate templates, see the YAMLconfiguration documentation. For furtherinformation about initialisation, see the stack init commanddocumentation. The stack new and stack initcommands have options and flags in common.
Looking closely at the output of the previous command, you can see that it builtboth a library called helloworld and an executable called helloworld-exe (onWindows, helloworld-exe.exe). We'll explain more in the next section, but, fornow, just notice that the executables are installed in a location in ourproject's .stack-work directory.
stack exec works by providing the same reproducible environment that was usedto build your project to the command that you are running. Thus, it knew whereto find helloworld-exe even though it is hidden in the .stack-workdirectory. Command stack path --bin-path to see the PATH in the Stackenvironment.
On Windows, the Stack environment includes the \mingw64\bin, \usr\binand \usr\local\bin directories of the Stack-supplied MSYS2. If yourexecutable depends on files (for example, dynamic-link libraries) in thosedirectories and you want ro run it outside of the Stack environment, youwill need to ensure copies of those files are on the PATH.
Reading the output, you'll see that Stack first builds the test suite and thenautomatically runs it for us. For both the build and test command, alreadybuilt components are not built again. You can see this by using thestack build and stack test commands a second time:
The Setup.hs file is a component of the Cabal build system which Stack uses.It's technically not needed by Stack, but it is still considered good practicein the Haskell world to include it. The file we're using is straightboilerplate:
The value of the resolver key tells Stackhow to build your package: which GHC version to use, versions of packagedependencies, and so on. Our value here says to useLTS Haskell 22.21, which implies GHC 9.6.5(which is why stack build installs that version of GHC if it is not alreadyavailable to Stack). There are a number of values you can use for resolver,which we'll cover later.
The value of the packages key tells Stack which project packages, locatedlocally, to build. In our simple example, we have only a single project package,located in the same directory, so '.' suffices. However, Stack has powerfulsupport for multi-package projects, which we'll elaborate on as this guideprogresses.
The package.yaml file describes the package in theHpack format. Stack has in-built Hpackfunctionality and this is its preferred package format. The default behaviour isto generate the Cabal file (here named helloworld.cabal) from thispackage.yaml file, and accordingly you should not modify the Cabal file.
It is also important to remember that Stack is built on top of the Cabal buildsystem. Therefore, an understanding of the moving parts in Cabal are necessary.In Cabal, we have individual packages, each of which contains a single Cabalfile, named .cabal. The Cabal file can define one or morecomponents: a library, executables, test suites, and benchmarks. It alsospecifies additional information such as library dependencies, defaultlanguage pragmas, and so on.
In this guide, we'll discuss the bare minimum necessary to understand how tomodify a package.yaml file. You can see a full list of the available optionsat the Hpack documentation. TheCabal User Guide is the definitive reference for theCabal file format.
As you can see from that path (and as emphasized earlier), the installation isplaced to not interfere with any other GHC installation, whether system-wide oreven different GHC versions installed by Stack.
stack clean deletes the local working directories containing compiler output.By default, that means the contents of directories in .stack-work/dist, forall the .stack-work directories within a project.
stack purge deletes the local stack working directories, including extra-deps,git dependencies and the compiler output (including logs). It does not deleteany snapshot packages, compilers or programs installed using stack install.This essentially reverts the project to a completely fresh state, as if it hadnever been built. stack purge is just a shortcut for stack clean --full
The build command is the heart and soul of Stack. It is the engine that powersbuilding your code, testing it, getting dependencies, and more. Quite a bit ofthe remainder of this guide will cover more advanced build functions andfeatures, such as building test and Haddocks at the same time, or constantlyrebuilding blocking on file changes.
Using the build command twice with the same options and arguments shouldgenerally do nothing (besides things like rerunning test suites), andshould, in general, produce a reproducible result between different runs.
Remember above when stack new selected someLTS snapshot for us?That defined our build plan and available packages. When we tried using thetext package, it just worked, because it was part of the LTS package set.
To add acme-missiles to the available packages, we'll use the extra-deps keyin the stack.yaml file. That key defines extra packages, not present in thesnapshot, that will be needed as dependencies. You can add this like so:
With that out of the way, let's dig a little bit more into these package sets,also known as snapshots. We mentioned the LTS snapshots, and you can get quitea bit of information about it at , including:
You can also see alist of all available snapshots. You'llnotice two flavors: LTS (for "Long Term Support") and Nightly. You can read moreabout them on theLTS Haskell GitHub page.If you're not sure which to use, start with LTS Haskell (which Stack will leantowards by default as well).
Let's explore package sets a bit further. Instead of lts-22.13, let's changeour stack.yaml file to use thelatest nightly. Right now, this is currently2024-03-20 - please see the snapshot from the link above to get the latest.
When passed on the command line, you also get some additional "short-cut"versions of snapshots: --snapshot nightly will use the newest Nightly snapshotavailable, --snapshot lts will use the newest LTS, and --snapshot lts-22will use the newest LTS in the 22.x series. The reason these are only availableon the command line and not in your stack.yaml file is that using them:
Alright, enough playing around with simple projects. Let's take an open sourcepackage and try to build it. We'll be ambitious and useyackage, a local package serverusing Yesod. To get the code, we'll use thestack unpack command from the root directory for all our Haskell projects:
You could manually create stack.yaml by omitting some packages to resolve theconflict. Alternatively you can ask stack init to do that for you byspecifying --omit-packages flag on the command line. Let's see how thatworks.
To simulate a conflict we will use acme-missiles-0.3 in yackage and we willalso copy yackage.cabal to another directory and change the name of the fileand package to yackage-test. In this new package we will useacme-missiles-0.2 instead. Let's see what happens when we command stack initagain:
7fc3f7cf58