Just to throw another use-case into the pool: I've been looking at how
to create TAGS for downloaded dependencies in my tool
`stack-tag`. Basically, stack-tag creates source tags for the exact
snapshot being used on a project and unifies them in a single TAGS file.
Right now, `stack unpack`
Okay, that sounds good. Thanks for the suggestion!
On Sun, Oct 21, 2018 at 1:14 AM Michael Snoyman wrote:
> Given that we're going to be mostly getting rid of that directory, I don't
> think it makes sense to add it. If the goal is to get access to the source
> code, using `stack unpack` is the
Given that we're going to be mostly getting rid of that directory, I don't
think it makes sense to add it. If the goal is to get access to the source
code, using `stack unpack` is the right way to go. We should probably ensure
that there's a flag available that will respect any local extra-deps
The specific question is:
Can stack be queried to display the location of the source folder (meaning,
where it is stored locally) for any given package in the current project's
build plan?
(And the unspecific question is whether this is a good idea.)
For example:
# stack.yaml
resolver:
I think this is too abstract a question to know how to answer it. What
questions do you want to ask?
Also, most of the usage of that directory will be changing drastically in the
next release of Stack due to the introduction of pantry, which handles
downloaded packages more efficiently.
> On
Hi,
I'm wondering if it's a bad idea whether to ask stack for information about
packages in .stack-work/downloaded/*. I would be asking stack about these
packages after calling the build command. Is this possible using the stack
package
in Hackage, or using the command line tool? Are there
