1
votes

When running stack sdist in my project directory, the stack.yaml file isn't included in the tarball (this seems to be expected).

Consequently, when I upload the tarball to hackage, then stack install mypackage it complains about missing dependencies (extra-deps) which I specified in the stack.yaml file.

$ stack install pandoc-placetable

Run from outside a project, using implicit global project config
Using resolver: lts-5.17 from implicit global project's config file: ~/.stack/global-project/stack.yaml
While constructing the BuildPlan the following exceptions were encountered:

--  Failure when adding dependencies:    
      spreadsheet: needed (>=0.1.3 && <0.1.4), not present in build plan (latest applicable is 0.1.3.4)
    needed for package: pandoc-placetable-0.4

--  While attempting to add dependency,
    Could not find package spreadsheet in known packages

Recommended action: try adding the following to your extra-deps in /Users/maurobieg/.stack/global-project/stack.yaml
- spreadsheet-0.1.3.4

Or what's the recommended way to make a hackage package stack-installable if it has further hackage dependencies?

Update: I just added extra-source-files: stack.yaml to the cabal file and the stack.yaml is indeed included in the tarbal of the newly published version. Nevertheless, stack install pandoc-placetable-0.4.1 still comes up with the same error.

I could also just tell people who don't want to install cabal-install on their system to clone from GitHub, then build with stack. Is that the recommended approach for tiny packages? Or should I ask them to include the dependency of pandoc-placetable (i.e. spreadsheet) in their global stack.yaml? Smells like polluting a global file...

1
Does the suggestion (extra-source-files: stack.yaml) in the thread you linked work? I would expect it to. Hackage package are not meant to be 'stack-installable' (stack doesn't do anything but call other programs which do all the work, so 'stack-installable' is just 'cabal-installable'), or you are meant to get the stack.yaml from your resolver (remember, package maintainers will likely want to support multiple compile version and will have multiple stack.yaml).user2407038
In addition to the previous comment, I'd recommend getting your package into Stackage: github.com/fpco/stackage#add-your-packageMichael Snoyman
@user2407038 extra-source-files doesn't help, see my update.mb21
@MichaelSnoyman my package consists of only one source code file, it's a really small pandoc filter that's not going to change much. Are we supposed to push small stuff like that to stackage as well? Won't there be too much administrative overhead for you guys? Also, I'll have to release a new package every few months, whenever the next lts comes along, even if my dependencies and code don't change at all, right? (please correct me if I'm wrong and take it as feedback about what information I gathered as a casual haskell dev)mb21
Relevant stack issue about using stack.yaml from hackage package: github.com/commercialhaskell/stack/issues/2122mgsloan

1 Answers

1
votes

As mentioned by @mgsloan in the comments above: There's an open stack issue about using stack.yaml from hackage package.

I guess until it's fixed I'll just tell people to clone from GitHub (or as mentioned by @MichaelSnoyman to stack unpack) and then cd into the newly created directory and stack install there.