{"action":"created","issue":{"url":"https://api.github.com/repos/haskell/haskell-platform/issues/207","labels_url":"https://api.github.com/repos/haskell/haskell-platform/issues/207/labels{/name}","comments_url":"https://api.github.com/repos/haskell/haskell-platform/issues/207/comments","events_url":"https://api.github.com/repos/haskell/haskell-platform/issues/207/events","html_url":"https://github.com/haskell/haskell-platform/issues/207","id":105286672,"number":207,"title":"Windows: Setup MSYS2","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},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-09-08T02:08:36Z","updated_at":"2015-09-09T04:39:29Z","closed_at":null,"body":"Goals:\r\n\r\n* MSYS2 is easily available for builds with both cabal-install and stack\r\n* The entire MSYS2 set of commands are not automatically added to the PATH (Note: I don't have this goal, and in my own Windows usage _like_ having these tools on my PATH. I'm just recording a requirement I _think_ I've heard from @mzero)\r\n* Ideal: possible to install new packages via `pacman`, and make those libraries available during builds\r\n\r\nMinGHC originally solved the MSYS problem using MSYS1, then moved to PortableGit. I finally found the portable installation of MSYS2 itself a few weeks ago, and stack master has moved over to that. There is no official release of stack with that change, but many users (myself included) have been testing it. I'd recommend going for that in the next HP, since it's the most official and most featureful option.\r\n\r\nSince code is worth a thousand words, here's the code from stack that installs MSYS2:\r\n\r\nhttps://github.com/commercialhaskell/stack/blob/master/src/Stack/Setup.hs#L849\r\n\r\nThe one catch is that, after unpacking the archive, you need to run the shell once to do some initialization, otherwise some utilities - at least pacman - will fail.\r\n\r\nDownload information on MSYS2 is available at https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml#L14.\r\n\r\nOnce MSYS2 is available on the OS, you need to be able to tell the build tools where to find it. Since the goal is to avoid cluttering PATH, I'd take two different routes:\r\n\r\n* stack can add support for recognizing some environment variable (e.g. STACK_MSYS2=*dir* or perhaps HASKELL_MSYS2=*dir*) to detect the location of the MSYS2 install, and from then on stack just does its usual thing of modifying the PATH for child processes\r\n* You can provide one of Neil's \"switcher\" batch scripts for cabal-install usage, which modifies the PATH to include all of these tools. See: https://github.com/fpco/minghc/blob/master/Installer.hs#L68"},"comment":{"url":"https://api.github.com/repos/haskell/haskell-platform/issues/comments/138777592","html_url":"https://github.com/haskell/haskell-platform/issues/207#issuecomment-138777592","issue_url":"https://api.github.com/repos/haskell/haskell-platform/issues/207","id":138777592,"user":{"login":"gbaz","id":1125849,"avatar_url":"https://avatars.githubusercontent.com/u/1125849?v=3","gravatar_id":"","url":"https://api.github.com/users/gbaz","html_url":"https://github.com/gbaz","followers_url":"https://api.github.com/users/gbaz/followers","following_url":"https://api.github.com/users/gbaz/following{/other_user}","gists_url":"https://api.github.com/users/gbaz/gists{/gist_id}","starred_url":"https://api.github.com/users/gbaz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gbaz/subscriptions","organizations_url":"https://api.github.com/users/gbaz/orgs","repos_url":"https://api.github.com/users/gbaz/repos","events_url":"https://api.github.com/users/gbaz/events{/privacy}","received_events_url":"https://api.github.com/users/gbaz/received_events","type":"User","site_admin":false},"created_at":"2015-09-09T04:39:28Z","updated_at":"2015-09-09T04:39:28Z","body":"I'm not keen on recognizing the same env variable as any other tool at this point, nor trying to share directories. This would be ideal, of course, but it raises too many issues in terms of co-ordination -- what if that tool decides it needs a slightly different version, etc. While it could work out quite nicely, it is just one more thing to go wrong.  As far as future co-ordination effort, once we have the precedent of a few tools doing this, then perhaps unification can be on the cards.\r\n\r\nSo it seems to me we have a twofold approach:\r\n\r\nA) bundle the platform with a switcher script\r\n\r\nB) _also_ work on a patch to cabal so that it can recognize an env variable (I would in fact suggest something more tool-agnostic in terms of msys etc such as CABAL_EXTRA_PATH) and auto-prepend that to the path prior to running configure scripts.\r\n\r\nWhenever that patch lands, great, we can stop the switcher script nonsense. Until then, support remains available.\r\n\r\n(And a third component could be to try to detect if an appropriate msys is in one of the \"usual suspect\" locations and offer the option to the user to use that instead of installing a new one? That way there is no magic, but it also lets the user try to leverage existing tools when they exist.)"}}