New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

interpreter: Don't make cached packages available that are not specified with `--package` #1208

Closed
soenkehahn opened this Issue Oct 21, 2015 · 7 comments

Comments

@soenkehahn

soenkehahn commented Oct 21, 2015

Consider the following script:

#!/usr/bin/env stack
-- stack --resolver lts-3.10 --install-ghc runghc

import Safe

main :: IO ()
main = do
  print $ headMay "foo"

This script depends on the package safe. It currently works without problems on my machine, but only because I already have the package safe cached for the specified snapshot. On machines where the package is not installed it fails with

Test.hs:4:8:
    Could not find module ‘Safe’
    Use -v to see a list of the files searched for.

It would be great if stack scripts would either fail or succeed independent of cache state. Then I could create stack scripts on my machine, copy them to different machines and be fairly sure that they will run.

@soenkehahn soenkehahn changed the title from interpreter: Don't make cached packages available without asking for them to interpreter: Don't make cached packages available that are not specified with `--package` Oct 21, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 1, 2015

There's a tension between making scripting as convenient as possible for "one-offs" and making them reproducible. My inclination is to lean toward the "one-off" case for this, and recommend making an actual project if you want proper reproducibility. I already find the -- stack ... header line gets unwieldy, and having to list all dependencies there would be much worse.

If we do want proper reproducible scripts, I think we'd have to considering adding support for an inline stack-yaml-like configuration in the script's header, rather than reproducing a bunch of those features on the command-line. But is it worth it? I'm inclined to think not.

@soenkehahn

This comment has been minimized.

soenkehahn commented Nov 3, 2015

I didn't really consider the use-case of one-off scripts, but that's a very good point.

Ideally I think we would have both: reproducible and one-off scripts. (This could be done with a command line switch or a separate command.) Any thoughts on this?

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 3, 2015

No objection to finding a way to optionally improve reproducibility for scripts. Simplest might be be to add a switch to stack runghc that requires dependencies to be explicitly listed.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 22, 2015

Note discussion of multiline script directive in #1394, which should probably be done before this.

Also, related discussion about adding a --standalone flag in #1388 (comment).

@rrnewton

This comment has been minimized.

Contributor

rrnewton commented Aug 11, 2016

--standalone will be great.

In the meantime, is there any better way to test whether your script has undeclared dependencies rather than having to manually create a stack.yaml file and paste in the dependencies? For long dependency lists, this is rather tiresome because it's a different textual format... i.e. reformatting --package foo --package bar to a list in the yaml file.

Personally, I've never wanted irreproducible scripts because I hop around machines and LTS versions so much that I don't mentally have any model whatsoever of the state of my cache on a given machine.

I also wanted to throw out there that there are other reasons to use the script interpreter rather than a full stack.yaml project config:

  • The interpreted code can be a lot faster to start up, especially if it's being edited frequently, like our plotting scripts.
  • It's also simply a repository clutter issue for us. If we have N little scripts, promoting each one to a directory, with a .cabal and a stack.yaml is at least three more files/directories per script.

harendra-kumar added a commit that referenced this issue Aug 12, 2016

Interpreter: Provide a way to hide implicit packages
Always pass all the explicitly specified packages in the script to ghc command
line. Also allow ghc options to be specified from the interpreter command. This
will give user the flixibility to, for example, use '-hide-all-packages' ghc
option. Like this:

{- stack runghc
    --package base
    --package exceptions
    --package transformers
    --package containers
    --package getopt-generics
    --package filepath
    --package path
    --package path-io
    --package process
    --package unix-compat
    --
    -hide-all-packages
-}

fixes #1208
@harendra-kumar

This comment has been minimized.

Collaborator

harendra-kumar commented Aug 12, 2016

I provided a fix in PR #2480 . The PR provides a way to pass ghc options from interpreter command which was not possible before. It passes all specified packages explicitly on ghc command line and allows you to pass -hide-all-packages from your script which will hide any implicit packages from the pkg-db.

A syntactic sugar in the form of a runghc option can also be provided. Though it will not be any shorter compared to passing -hide-all-packages directly to ghc, it will perhaps be more intuitive. One won't have to refer to the ghc manual as well as stack manual to know how to specify ghc options to runghc. For example using --no-implicit-packages along with --packages is more intuitive than ending the command with a ghc option like this-- -hide-all-packages.

@harendra-kumar

This comment has been minimized.

Collaborator

harendra-kumar commented Aug 12, 2016

I also wanted to throw out there that there are other reasons to use the script interpreter rather than

You don't have to justify this :-) Haskell is a great scripting language and we should make scripting a first class feature. Maybe we can replace python with Haskell one day.

harendra-kumar added a commit that referenced this issue Aug 13, 2016

Interpreter: Provide a way to hide implicit packages
Always pass all the explicitly specified packages in the script to ghc command
line. Also allow ghc options to be specified from the interpreter command. This
will give user the flixibility to, for example, use '-hide-all-packages' ghc
option. Like this:

{- stack runghc
    --package base
    --package exceptions
    --package transformers
    --package containers
    --package getopt-generics
    --package filepath
    --package path
    --package path-io
    --package process
    --package unix-compat
    --
    -hide-all-packages
-}

fixes #1208

@borsboom borsboom removed the in progress label Aug 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment