stack install with extra-deps

[NightRa]

When doing stack install of an application which has extra-deps, stack asks to add these packages to the global extra-deps of the user. This is undesirable.

For example:
stack install ghc-mod
where ghc-mod has an extra-dep:

While constructing the BuildPlan the following exceptions were encountered:

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

--  Failure when adding dependencies:
      cabal-helper: needed (==0.6.* && >=0.6.0.0), not present in build plan (latest is 0.6.1.0)
    needed for package: ghc-mod-5.4.0.0

Recommended action: try adding the following to your extra-deps in C:\Users\Ilan\AppData\Roaming\stack\global\stack.yaml
- cabal-helper-0.6.1.0

[NightRa]

I suppose the problem is where to install this dependency and how to avoid installing it globally to avoid collisions.
Possibly create a temporary project dir for the apptication in ~/.stack and then install into that folder's .stack-work?

[borsboom]

I see you've already discovered that ghc-mod is in nightly, so that should resolve that particular issue. I'm not sure if it's so bad, really, to put extra-deps in the implicit global project. It won't effect any real projects and means that future implicit global "stack installs" would get to use it as well.

[NightRa]

@borsboom Up until now I've been just cloning the repo and installing from source, so I thought maybe it could have been done automatically.
Having to navigate to that global config, opening it and editing it is quite a bit more than just typing the command for a beginner, when I introduce people to haskell.
At least this particular case is sort of resolved.

Anyhow, if this were to be implemented, I think most of the machinery for this is already there, with extra-deps or git-locations being cloned into isolated locations.

[snoyberg]

I don't consider the current situation problematic, I'd move to close this, since (1) the advice is valid, and (2) it's trivial to create a new stack.yaml in a different directory if desired.

[mfine]

:+1: for passing --extra-deps on the command line. I have a tool with extra-deps in its stack.yaml, and when I try and globally install it, it fails, necessitating me to add the extra-deps to the global stack.yaml. I'm very much trying to install something globally without access to the cabal file or stack.yaml (making the passing of extra-deps already brittle). Is there a better way to handle that?

The tool's stack.yaml:

extra-deps:
- amazonka-1.3.2
- amazonka-core-1.3.2
- amazonka-s3-1.3.2
- amazonka-swf-1.3.2
- shelly-1.6.4.1

The workaround in installing the tool in a container:

RUN apt-get update
RUN apt-get install -y --force-yes wget
RUN wget -q -O- https://s3.amazonaws.com/download.fpcomplete.com/debian/fpco.key | apt-key add -
RUN echo 'deb http://download.fpcomplete.com/debian/jessie stable main'| tee /etc/apt/sources.list.d/fpco.list
RUN apt-get update
RUN apt-get install -y --force-yes stack
RUN stack update
RUN stack setup
RUN echo 'extra-deps:' > /root/.stack/global-project/stack.yaml
RUN echo '- amazonka-1.3.2' >> /root/.stack/global-project/stack.yaml
RUN echo '- amazonka-core-1.3.2' >> /root/.stack/global-project/stack.yaml
RUN echo '- amazonka-s3-1.3.2' >> /root/.stack/global-project/stack.yaml
RUN echo '- amazonka-swf-1.3.2' >> /root/.stack/global-project/stack.yaml
RUN echo '- shelly-1.6.4.1' >> /root/.stack/global-project/stack.yaml

Not sure how well supported the global install path is intended to be supported - something feels off here about having these extra deps in multiple places now :(

Hope this feedback helps.

[akhra]

This has been dead for a while, but another case where --extra-deps would be very nice is stack script. As far as I can tell there is currently no way for a stand-alone, portable script file to use anything not in Stackage.

[snoyberg]

You can refer to a custom snapshot with stack script to get extra-deps into place.

[akhra]

But unless I'm missing something, that kills "stand-alone, portable." You need access to that snapshot definition, which has to live in a file somewhere.

[snoyberg]

It can also live in a URL.

On Tue, Oct 9, 2018, 10:49 PM Theodore Lief Gannon [e-mail]
wrote:

But unless I'm missing something, that kills "stand-alone, portable." You
need access to that snapshot definition, which has to live in a file
somewhere.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/commercialhaskell/stack/issues/1144#issuecomment-428326985,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADBByuI7mz-VwKTX39WoY0Cf8dygtMBks5ujP3jgaJpZM4GMyRG
.

[akhra]

That's an option, but it really feels like overkill. I can email a script, or just send it as a Slack message; but for anyone to run it I have to host another file somewhere?

I suppose the adjective I should be using is "self-contained."