了解.cabal和stack.yaml文件中的版本控制

Question

查看我的堆栈项目的project.cabal

name:                project
version:             0.1.0.0
-- synopsis:
-- description:
homepage:            https://github.com/githubuser/project#readme
license:             BSD3
license-file:        LICENSE
author:              Author name here
maintainer:          example@example.com
copyright:           2017 Author name here
category:            Web
build-type:          Simple
extra-source-files:  README.md
cabal-version:       >=1.10

executable project-exe
  hs-source-dirs:      app
  main-is:             Main.hs
  ghc-options:         -threaded -rtsopts -with-rtsopts=-N
  build-depends:       base
                     , project
                     , servant-server
                     , base-compat
                     , wai
                     , aeson
                     , blaze-markup
                     , blaze-html
                     , directory
                     , warp
                     , http-media
                     , lucid
                     , time
                     , bytestring
                     , attoparsec
                     , string-conversions
                     , mtl
                     , servant-lucid
  default-language:    Haskell2010
  ghc-options:
    -fwarn-unused-imports

不需要指定每个库的版本吗？换句话说，我似乎只指定了库，而没有指定版本，例如servant-server。

看着我的stack.yaml，我看到：

resolver: lts-9.5

也许该版本，即lts-9.5，指定了每个依赖项的版本？

简而言之，我问的是stack项目中的版本控制。

Answer 1

正确地说，没有必要指定库的版本(从.cabal文件解析器不需要它的意义上说)。

正确的是，stack.yaml的lts-9.5解析器指定了大量黑客攻击的固定版本，可能包括该cabal文件中列出的所有内容。您可以看到lts-9.5 on the Stackage website隐含的包/版本对的确切列表。

对于哪种机制(在.cabal文件中的版本约束或在stack.yaml中通过指定固定的包/版本对列表的版本约束)最适合指定版本界限，社区在某种程度上存在分歧，但我认为我们可以达成一致，即您应该至少使用这两种机制中的一种。因此，虽然在技术上没有必要以任何方式指定版本限制，但我鼓励您以某种方式这样做。如果您遗漏了版本限制，那么您的项目很可能无法正确构建(无论是现在还是将来的某个时候)。

就我个人而言，我也认为在.cabal文件本身中包含版本限制是最好的做法，即使这只是为了准确地确定堆栈解析器将选择的限制，以便出于某种原因而更喜欢使用cabal的人在使用您的包时会遇到更少的麻烦。