-
Notifications
You must be signed in to change notification settings - Fork 207
Find and run cabal in user original $PATH #1406
Conversation
I like the idea, but the approach is very hacky indeed. Is it a possible alternative to use |
I thought in use that at first but unfortunately in windows Imho the right one would be to have in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is no better cross platform solution, this PR is fine
I am having issues on Debian with tests failing when I build locally, but passing fine on CI, e.g. https://circleci.com/workflow-run/57c08f4c-eca4-46af-bedd-97c3ae0d0835. I wonder if this cached cabal could be the issue for me. |
i've opened an issue in |
I've updated the pr:
This could be merged, as the stack issue has not feedback and there is no better alternative |
Im ok with this. @fendor should we merge this now? |
cabal
executable used withinstack install.hs
executions after a firststack install.hs stack-install-cabal
is the cached in$STACK_ROOT/snapshots/{hash}/bin
. The cause isstack
prepends that directory to the$PATH
environment variable. That supposes:$PATH
after runningstack install.hs stack-install-cabal
, another invocation doesn't copy again the cabal executable, cause the version cached by stack is found. (thanks @jchia for detected it)stack install.hs cabal-*
use that cached version and no the original one, so if you upgrade your cabal in$PATH
to3.0.0.0
stack will continue using its cached version, (currently2.4.1.0
)To avoid it i had to remove manually
$STACK_ROOT/snapshots/{hash}/bin
from$PATH
, an ugly ugly hack, but i didint find better way to do it (via stack flags or alternative env vars)I think this one would fix haskell/vscode-haskell#131