stack list-dependencies gives the same output regardless of target

[dcastro]

General summary/comments (optional)

When you have a project with multiple test suites (e.g. unit-a and unit-b), stack list-dependencies <unit-a | unit-b> will return a list with all the dependencies of all the test suites. I expected it to return the dependencies of the specified target only.

Steps to reproduce

$ stack new mytest && cd mytest && stack init && stack build

Change package.yaml so that it contains 2 test suites with different dependencies:

tests:
  unit-a:
    main:                Spec.hs
    source-dirs:         test
    dependencies:
    - mytest
    - hspec

  unit-b:
    main:                Spec.hs
    source-dirs:         test
    dependencies:
    - ace

$ stack list-dependencies mytest:test:unit-a --depth 1
ace 0.6
base 4.10.1.0
hspec 2.4.4
mytest 0.1.0.0

$ stack list-dependencies mytest:test:unit-b --depth 1
ace 0.6
base 4.10.1.0
hspec 2.4.4
mytest 0.1.0.0

Expected

I expected the list of dependencies for unit-b to not include hspec and mytest.
I expected the list of dependencies for unit-a to not include ace.

$ stack list-dependencies mytest:test:unit-a --depth 1
base 4.10.1.0
hspec 2.4.4
mytest 0.1.0.0

$ stack list-dependencies mytest:test:unit-b --depth 1
ace 0.6
base 4.10.1.0

Actual

Stack printed the same list of dependencies for both unit-a and unit-b, and that list includes the dependencies of both test suites.

Stack version

 $ stack --version
Version 1.6.1, Git revision f25811329bbc40b0c21053a8160c56f923e1201b (5435 commits) x86_64 hpack-0.20.0

Method of installation

Official binary from haskellstack.org

[mgsloan]

Thanks for the report! It should be possible to resolve this, but it will not exactly be a trivial change.

I believe this is a symptom of what Cabal considers to be dependencies of a configure. I think it will still require the deps of all test suites, because --enable-tests has been passed to it, regardless of which specific tests will be built. I'm not sure whether this is resolved in Cabal-2.0. I believe there's a ticket for this somewhere.

So, the current behavior is consistent with what would be installed if those targets were built, rather than the actual direct deps of those targets. I'm not sure which behavior is preferable, really, so marking this as a discussion issue rather than a bug.

[dcastro]

Thanks for the reply @mgsloan.

Ah, that makes sense now. I see why keeping the current behaviour would be preferable.
Do you think an option could be added to list-dependencies (e.g. --direct-deps) that lists only the direct dependencies?

Or maybe add a new command to stack ide?

For what it's worth, my use case is this: I'm working on an editor plugin (similar to this) that provides code lenses for running tests (i'm only going to support hspec for now). On startup, the plugin checks which test suites there are (using stack ide targets and filtering for :test:), and then checks which depend on hspec. For each hspec test suite found, we load an instance of intero with that target. If that suite depends on the package's library, then we load package:lib too. As it is, I'll have to load an instance of intero for all test suites by default, even if only 1 of them are actually hspec suites which may end up using lots of memory. I'll also have to allow the user to override the default behaviour and specify which suites he wants to actually load.

[mgsloan]

@dcastro I see! That would be a lot of instances of intero. I think it might make sense for you to do something like stack ghci --with-ghci intero --no-load --test. Then, you can drive it by doing specific ":load ..." to load particular main modules and run main. Downside of this is that it combines all of the settings for the test-suite stanzas, which isn't really a principled thing to do. Seems to work ok for most projects.

This still leaves the problem of detecting the dependency on hspec. Certainly could have an option for --direct-deps, feel free to open a PR for that. Alternatively, this ought to work:

• Run stack query and parse it (it's yaml)
• Parse all the local cabal files and check if the test-suites have hspec in their deps.

Note that if the project has never been built, then cabal files may not be generated. stack build --dry-run will run hpack.

[dcastro]

Thanks for the tip @mgsloan! I didn't know about stack query, that really helped!

Regarding --no-load, I can't really do that, because I'm using intero's :all-types command to scan the files for hspec tests (by looking for expressions of type SpecM () ()) and the tests' names.

I also considered loading a bunch of test-suites into one instance of intero, but then :all-types would give me all the expressions for all test suites, and I wouldn't be able to tell which test-suite a test belongs to (to the best of my knowledge).

Thanks to your tip, I wrote a little stack script that outputs all the direct dependencies of each component of a stack project: it calls stack query, and then uses the Cabal library to parse each cabal file. Here: https://github.com/dcastro/hsscripts/blob/master/src/DirectDeps.hs

(I considered using the stack library directly, instead of calling stack query, but the lib takes ~13 mins to build... I think that would be bad user experience if the extension took 13 mins to load the first time it runs).

Thanks again!

[mgsloan]

Great, glad it worked out!

Changing the behavior of list-dependencies is indirectly tracked by #2800 and other issues, so closing this. In other words, since list-dependencies uses the same info as used for building, once the build behavior changes, this will change too.

[dcastro]

Thanks, I'll subscribe that issue and keep an eye on it!