{"action":"created","issue":{"url":"https://api.github.com/repos/commercialhaskell/stack/issues/828","labels_url":"https://api.github.com/repos/commercialhaskell/stack/issues/828/labels{/name}","comments_url":"https://api.github.com/repos/commercialhaskell/stack/issues/828/comments","events_url":"https://api.github.com/repos/commercialhaskell/stack/issues/828/events","html_url":"https://github.com/commercialhaskell/stack/issues/828","id":102294063,"number":828,"title":"Copying executables when installing is fragile with packages relying on the paths in Cabal's Paths_<pkg-name> module","user":{"login":"DanielG","id":199218,"avatar_url":"https://avatars.githubusercontent.com/u/199218?v=3","gravatar_id":"","url":"https://api.github.com/users/DanielG","html_url":"https://github.com/DanielG","followers_url":"https://api.github.com/users/DanielG/followers","following_url":"https://api.github.com/users/DanielG/following{/other_user}","gists_url":"https://api.github.com/users/DanielG/gists{/gist_id}","starred_url":"https://api.github.com/users/DanielG/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DanielG/subscriptions","organizations_url":"https://api.github.com/users/DanielG/orgs","repos_url":"https://api.github.com/users/DanielG/repos","events_url":"https://api.github.com/users/DanielG/events{/privacy}","received_events_url":"https://api.github.com/users/DanielG/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-08-21T04:12:31Z","updated_at":"2015-08-24T09:59:44Z","closed_at":null,"body":"Since `stack install` is merely an alias for copying executables after building them this means that the Paths_<pkg-name> module doesn't get re-generated for the _actual_ installation prefix but rather remains at pointing to somewhere in `.stack-work`. This is a real problems for programs or libraries that rely on these paths being correct.\r\n\r\n`cabal install` does this correctly and rebuilds the whole package with the proper paths in this module.\r\n\r\nMy specific use case is cabal-helper where, in the library, I have to use `libexecdir` to find the wrapper executable (since I don't want that to show up on the user's PATH). Since there isn't such a thing as LIBEXECPATH I'm kind of stuck here as I can't think of another way to find my executables in libexec.  "},"comment":{"url":"https://api.github.com/repos/commercialhaskell/stack/issues/comments/134124185","html_url":"https://github.com/commercialhaskell/stack/issues/828#issuecomment-134124185","issue_url":"https://api.github.com/repos/commercialhaskell/stack/issues/828","id":134124185,"user":{"login":"snoyberg","id":49415,"avatar_url":"https://avatars.githubusercontent.com/u/49415?v=3","gravatar_id":"","url":"https://api.github.com/users/snoyberg","html_url":"https://github.com/snoyberg","followers_url":"https://api.github.com/users/snoyberg/followers","following_url":"https://api.github.com/users/snoyberg/following{/other_user}","gists_url":"https://api.github.com/users/snoyberg/gists{/gist_id}","starred_url":"https://api.github.com/users/snoyberg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/snoyberg/subscriptions","organizations_url":"https://api.github.com/users/snoyberg/orgs","repos_url":"https://api.github.com/users/snoyberg/repos","events_url":"https://api.github.com/users/snoyberg/events{/privacy}","received_events_url":"https://api.github.com/users/snoyberg/received_events","type":"User","site_admin":false},"created_at":"2015-08-24T09:59:44Z","updated_at":"2015-08-24T09:59:44Z","body":"Alright, reviewing this again, I think I'm starting to understand what you're saying, and where the misunderstanding is starting. For future reference, it would be a lot easier to follow a bug report if it followed the recommended [bug reporting guidelines](https://github.com/commercialhaskell/stack/blob/master/CONTRIBUTING.md).\r\n\r\nCurrent situation: all paths in the `Paths_*` module refer to local directories inside of the stack-work directory. AFAICT, despite the implications in the initial bug report, this doesn't break anything: all executables are generated with paths that actually exist. Is this correct?\r\n\r\nThe concern that you have is that, when copying an executable from .stack-work/foo/bar to ~/.local/bin, it will still refer to data-files and other such files in .stack-work. This, again, doesn't result in anything being broken. Your concern is that, if in the future the user deletes the .stack-work directory, things will break. Are we still on the same page?\r\n\r\nAnd just to round things out: it's not technically true that paths will always be under .stack-work. If the package is part of the snapshot, it will instead be placed inside ~/.stack. Perhaps that's part of the problem you're worried about.\r\n\r\nI have comments to make about this situation, but I want to confirm that we're actually talking about the same thing."}}