-
Notifications
You must be signed in to change notification settings - Fork 841
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
stack ghci/repl with internal sublibraries only works after a build #4148
Comments
Ensure we build before ghci, due to #4148.
@mihaimaruseac it would be good to get this working or add a note to the docs, before the next release. |
I'm travelling at the moment, so won't be able to get it working, most likely. Will come back to this on Friday and do one or the other |
Related: #2790 (possibly a duplicate) |
Added documentation for this, will try solving it later when I get some time to dwell deep into the code. |
I have this problem on 1.9.1 also (just fyi) |
It hasn't been fixed — just documented, for now. |
Yeah, just wanted to bump this issue. Any idea why it's happening? I'd love to help but I'd need some pointers to have a chance (aside: why are there 'z's interspersed with the internal library name?). |
I'm sorry, didn't get a chance to look into this :( Probably I'll get a chance next week or the one after, after HCAR is released. The z's are just a name mangling scheme. |
I get this issue with
|
Seems there has been a regression and now #4564 has the up to date status of this issue |
Using an internal library led to an error with "stack ghci" that also affected by IDE. It seems to be related to this stack issue, but wasn't fixed by running "stack build" first: commercialhaskell/stack#4148
Is anyone else still running into this issue? I think I'm running into something related with stack |
@austinvhuang I just ran into this today on a stack version 4 commits after what you have. |
@austinvhuang I'm running into this today too; Stack |
I tried a
|
Reopening in this case. |
I am running into this in the |
@mihaimaruseac @mpilgrem : This issue has a milestone |
@andreasabel, I've cleared the 'milestone' label as it was misleading. I'll likely find a different way of labelling the most important issues. I consider this issue to be one of the most important (in the top 3) because it interferes with the mechanism that HLS uses to get information from Stack. |
Regarding implementation, I thought it was something easy back in 2018, but I realized I needed much more time to understand Stack's codebase. Then had a job change and didn't get a chance to look much into it, but hoping to be able to pick it again in the enar future. |
To confirm: this still affects the spec-version: 0.36.0
name: ghciTest
version: 0.1.0.0
dependencies:
- base >= 4.7 && < 5
library:
source-dirs: src
dependencies:
- sub
internal-libraries:
sub:
source-dirs: sub
|
The command that fails is this (reformatted):
The command that succeeds is this (reformatted), the difference is the
|
Also hitting this, with HLS... bump + subscribe.
|
@ulidtko, |
@mpilgrem yes, using hand-written cradle: cradle:
stack:
- path: ./app/Apiserver.hs
component: my-acme-package:exe:apiserver
- path: ./test
component: my-acme-package:test:test
- path: ./src
#component: my-acme-package:lib:my-internal-sublib
#-- Can't specify the correct component name; it also fails to autodetect,
#-- because of https://github.com/commercialhaskell/stack/issues/4148
#-- Point HLS to "this directory" instead, and hope for the best.
component: . Something I failed to figure out and gave up on: Cabal docs, logs & source seem to suggest that these "internal sublibs" are also cabal package components. Aren't they? However all that looks like just stack lacking proper support for named/internal/sub- libs. For example here, Cabal defines ComponentName as: -- Libraries live in a separate namespace, so must distinguish
data ComponentName
= CLibName LibraryName
| CNotLibName NotLibComponentName and LibraryName is either the single data LibraryName
= LMainLibName
| LSubLibName UnqualComponentName So naturally, we'd think about named sublibs as cabal package components — and therefore, valid stack targets — but it's guessable that actually they're heavily specialcased in stack, and supported very differently than other types of components. |
General summary/comments (optional)
When running
stack ghci
on a fresh clone of a project having internal libraries, the attempt fails withHowever, if one first
stack build
s then the subsequentstack ghci
succeeds.Found while working on #4142 and will probably work on it in the coming weeks.
Steps to reproduce
test/integration/tests/3926-ghci-with-sublibraries/files
rm -rf .stack-work
to start from a clean statestack ghci
and see that it failsstack build
and thenstack ghci
and it succeedsExpected
Both step 3 and 5 should succeed.
Actual
Only step 3 succeeded
Stack version
Method of installation
Git clone
The text was updated successfully, but these errors were encountered: