mirror of
https://github.com/sdiehl/wiwinwlh.git
synced 2024-08-16 23:40:41 +03:00
Write more
This commit is contained in:
parent
3cdeaba85d
commit
06fd31632d
@ -32,6 +32,8 @@ This text is authored by Stephen Diehl.
|
||||
\item Github: https://github.com/sdiehl
|
||||
\end{enumerate}
|
||||
|
||||
Special thanks for Erik Aker for copyediting assitance.
|
||||
|
||||
Copyright \textcopyright \ 2009-2020 Stephen Diehl
|
||||
|
||||
This code included in the text is dedicated to the public domain. You can copy,
|
||||
|
29
tutorial.md
29
tutorial.md
@ -186,7 +186,7 @@ To modify your shell to include ghc and cabal.
|
||||
$ source ~/.ghcup/env
|
||||
```
|
||||
|
||||
Or permanently add the following to your `.bashrc` or `.zshrc` file:
|
||||
Or you can permanently add the following to your `.bashrc` or `.zshrc` file:
|
||||
|
||||
```bash
|
||||
export PATH="~/.ghcup/bin:$PATH"
|
||||
@ -201,12 +201,13 @@ package level. So, why are there two different package managers?
|
||||
|
||||
The simplest explanation is that Haskell is an organic ecosystem with no central
|
||||
authority, and as such different groups of people with different ideas and
|
||||
different economic interests about optimal packaging built around two different
|
||||
models. The interests of an organic community don't always result in open source
|
||||
convergence, however the ecosystem has seen both package managers reach much
|
||||
greater levels of stability as a result of collaboration. In this article I
|
||||
won't make a preference which system to use, this is best left up to the reader
|
||||
to experiment and use the system which best your or your company's needs.
|
||||
different economic interests about optimal packaging built their own solutions
|
||||
around two different models. The interests of an organic community don't always
|
||||
result in open source convergence; however, the ecosystem has seen both package
|
||||
managers reach much greater levels of stability as a result of collaboration. In
|
||||
this article, I won't offer a preference for which system to use: it is left up
|
||||
to the reader to experiment and use the system which best suits your or your
|
||||
company's needs.
|
||||
|
||||
Project Structure
|
||||
-----------------
|
||||
@ -233,9 +234,9 @@ file structure:
|
||||
└── .ghci # ghci configuration
|
||||
```
|
||||
|
||||
More complex projects consisting of multiple components will have use a multiple
|
||||
projects like above, but nested in subfolders with a `cabal.project` or
|
||||
`stack.yaml` in the root of the repository.
|
||||
More complex projects consisting of multiple components will include multiple
|
||||
project directories like that above, but these will be nested in subfolders with
|
||||
a `cabal.project` or `stack.yaml` in the root of the repository.
|
||||
|
||||
```bash
|
||||
.
|
||||
@ -246,8 +247,8 @@ projects like above, but nested in subfolders with a `cabal.project` or
|
||||
└── cabal.project # cabal project configuration
|
||||
```
|
||||
|
||||
An example Cabal project `cabal.project1` for the above multi-component library
|
||||
repository would look like:
|
||||
An example Cabal project file, named `cabal.project1` above, this
|
||||
multi-component library repository would include these lines.
|
||||
|
||||
```yaml
|
||||
packages: ./lib-one
|
||||
@ -255,8 +256,8 @@ packages: ./lib-one
|
||||
./lib-three
|
||||
```
|
||||
|
||||
While an example Stack project `stack.yaml` for the above multi-component library
|
||||
repository would be:
|
||||
By contract, an example Stack project `stack.yaml` for the above multi-component
|
||||
library repository would be:
|
||||
|
||||
```yaml
|
||||
resolver: lts-14.20
|
||||
|
Loading…
Reference in New Issue
Block a user