dependency not getting installed in .stack-work with stack 1.3.0 #2849
Comments
|
Hmm... I filed #2845, but I'm not sure it's related (or even a bug!). I was using 1.2.1, as noted in the ticket. |
|
However, I can reproduce this bug using Expected output: (I also tried |
|
It also doesn't have to do with the forked |
|
Here's a log of |
|
Alternatively, require that |
|
@mgsloan No problem, but can you clarify what you mean by that last comment? |
|
@mgsloan the source of the issue has been identified, but I'm not sure that we know that the way the behavior happens is indeed the desired result. At any rate, your understanding is not correct because I'm testing right now to see if workaround from @mitchellwrosen succeeds here. Again, not sure that it's the correct answer or a workaround for something that isn't right in stack. |
|
@wolftune It's not a workaround; as I said the change to not treat packages with |
|
Confirmed resolution from @mitchellwrosen — but I don't myself understand the meaning here of I agree this is thus solved, as far as I can tell. Perhaps the erroneous suggestion from @mgsloan is just a red herring. |
|
Well, looking over the commit message I don't actually know for sure if @snoyberg realized he was changing the behavior of @wolftune as far as I know, you have a forked version of |
As of stack 1.2.1 the yesod binary won't get installed in .stack-work unless we make this change. Everything works fine as far as I can tell with this resolution. See commercialhaskell/stack#2849
|
@mitchellwrosen no, that wasn't a reason at all (as far as I thought / know). The reason for the fork was to work with some new TH we added. See: |
|
And, in conjunction with that, I don't find it transparent (to me at least) whether the extra-dep true or false variable would be a concern for this case (or similar cases) |
|
Err, I worded that wrong, but I meant you forked it to change it, "it" being an executable component and not a library. |
|
That sounds right… since we use yesod-bin to run essentially yesod-devel, we need it to process our code correctly. I think our separate special build script runs the install of yesod-bin perhaps. At any rate, with our setup now, nobody manually runs |
|
And re: your last second-to-last comment, right, I think I agree, and I'm not sure that the fix was necessarily the right one (for reasons I tried to outline above but will reiterate): it's now not possible to have a forked version of an executable as part of the definition of a stack project, unless the package containing the executable is a "top-level" one. My terminology is off, but I hope I'm making sense. |
Sounds like it could be a real problem with stack that should be at least considered and reflected upon by stack devs to figure out what to do or if this limitation is acceptable… |
|
@mgsloan perhaps you can now reflect on the situation enough to determine the right course of action… maybe a new issue should be opened that specifically clarifies this problem as @mitchellwrosen is describing it? I'm certainly not sure of my understanding at this point. |
|
This does look like a bug to me, mea culpa. Reopening. Does anyone have a recommendation on the best behavior here? I think the original issue I was dealing with is still a real one, but perhaps the logic needs to be closer to "only treat it as a target if it's explicitly spelled out." |
|
OK, after a bit more research into this:
I'll open up a PR now, I'd appreciate if someone could test this use case against that PR once available. |
|
@snoyberg can you point me quickly to how to build locally from the particular git branch? |
|
|
right, duh. |
This reverts commit 31c6588. It turns out it was a stack bug after all, see commercialhaskell/stack#2849
|
@snoyberg I was able to build and run as expected using the stack from that PR, so confirmed fixed here |
Local extra-dep packages can be targets #2849
|
Since the fix has been confirmed, closing. |
related to #2845 this is specifically occurring with http://github.com/snowdriftcoop/snowdrift
Tested on multiple systems (all Linux-based)
With Stack 1.2.0, everything is fine. With Stack 1.3.0, the yesod binary is not found. It's not getting put into .stack-work correctly.
If I build successfully with stack 1.2.0, I can keep the stack-work, then build with stack 1.3.0 and still have things work because the binary built before is still present.
This probably relates to snowdrift using an alternate forked version of yesod-bin with a git address. It seems stack 1.3.0 has a bug where it isn't installing binaries in stack-work correctly when the binary comes from an extra dependency…
The text was updated successfully, but these errors were encountered: