Ask stack for local filepath of downloaded repo after compilation

[daniel.m...@gmail.com]

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 any suggestions for this?

Thanks,

Dan Fithian

[Michael Snoyman]

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.

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stac...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/bbdd3ea4-a3f3-4d91-9fae-375c0e5c0f65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Burton]

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: lts-12.0

packages:

- .

- location:

    git: ...
    commit: ...

  extra-dep: true
  subdirs:

  - bar

Can stack tell me where the `bar` package source has been downloaded to? ( Current answer would probably be ./.stack-work/downloads/$SOME_HASH/bar/, discovering $SOME_HASH being the difficult part, esp. if stack has downloaded multiple commits from this repo over time.)

If this cannot already be done with the existing CLI, perhaps it would be worthwhile to open a feature request. It seems like the sort of capability one might expect to find under `stack path`.

-- Dan Burton

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/D56D8F40-9750-4FD8-A379-9D727FB106B5%40snoyman.com.

[Michael Snoyman]

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 for unpacking.

[Dan Fithian]

Okay, that sounds good. Thanks for the suggestion!

[Christopher Reichert]

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` fails on GitHub project URLs. I'd like to
understand this problem better but I admit I haven't visited it in a
while.

Regards,

Dan Fithian <daniel.m...@gmail.com> writes:

> Okay, that sounds good. Thanks for the suggestion!
>
> On Sun, Oct 21, 2018 at 1:14 AM Michael Snoyman <mic...@snoyman.com> 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 right way to go. We should probably
>> ensure that there's a flag available that will respect any local extra-deps
>> for unpacking.

--
Christopher Reichert - https://creichert.io