dfithian / prune-juice

Prune unused Haskell dependencies.
MIT License
48 stars 4 forks source link

Show unused dependencies per Cabal component #11

Open elldritch opened 3 years ago

elldritch commented 3 years ago

This would be great for projects where e.g. I might have an executable component and a library component and some of my dependencies are used by my executable (e.g. optparse-applicative) but are accidentally and unnecessarily imported by my library.

elldritch commented 3 years ago

I was originally seeing this issue with https://github.com/liftM/tweetogram/blob/ea675ecde118b6f1915640379febce11e375d009/tweetogram.cabal, which has clearly unused dependencies in both library and executable components. However, after I dug into the code, it seems like prune-juice is actually supposed to display this information, but seems not to.

I've patched prune-juice to do the right thing in https://github.com/liftM/prune-juice/commit/39d59604a725c1ad5d95f33425443428f77b96c0, although I haven't yet made this a PR (since my base is quite a bit farther ahead than upstream).

dfithian commented 2 years ago

👍 on this. Once we can get the LTS upgrade in, we can add this, though since it'll come after https://github.com/dfithian/prune-juice/pull/12 it'll need to be added to Data.Prune.Apply.

dfithian commented 2 years ago

Rethinking this after the latest PR, it's unclear to me if/how we would show the unused dependencies in this situation because we can't necessarily apply them. Perhaps there could be a command line switch. I'll think about it while you fix up the PR.

elldritch commented 2 years ago

we can't necessarily apply them.

Why can't they be applied? The way I'd apply them as a human is to remove the unused packages from the respective library or executable where those packages are listed as build-depends.

I haven't actually looked at how smart/safe application strategies work - I forked from a version of prune-juice before --apply was merged. I'll take a look at that source once I find some time, but my guess is that something about the implementation precludes component-specific modifications?