Question

查看我的堆栈项目＆＃39; 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＆＃39; lts-9.5解析器指定大量Hackage的固定版本，可能包括该cabal文件中列出的所有内容。您可以查看lts-9.5 on the Stackage website隐含的软件包/版本对的确切列表。

社区对于哪种机制（.cabal文件中的版本约束或版本约束，通过在stack.yaml中指定固定的包/版本对列表）最适合指定版本边界，在某种程度上存在分歧，但是我想我们可以团结一致，你应该使用这两种机制中的至少一种。因此，虽然技术上没有必要以任何的方式指定版本边界，但我鼓励您以某种方式这样做。如果省略版本范围，您的项目很可能无法正确构建（无论是现在还是将来的某个时间）。

就个人而言，我也认为最佳做法是在.cabal文件本身中包含版本边界，即使这只是为了修复堆栈解析器选择的界限，因此，那些因为某种原因而喜欢使用阴谋的人会减少你的包裹的麻烦。

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

1 个答案: