You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem with this library is that it bakes the absolute path of the GHC installation into the compiled binary, but then if the binary is copied to another computer, the GHC installation might be in a different path and the binary won't work.
I propose that this library should transparently read from an environment variable called GHC_HOME first, if it exists then use that, otherwise fallback to the compiled-in path.
Other languages have a similar environment variable, for example: JAVA_HOME and PYTHONHOME.
The current workaround is to simply write the code yourself to read from GHC_HOME environment var and then fallback to ghc-paths, but having the code in this library would help to standardize my proposed GHC_HOME environment variable throughout the Haskell ecosystem.
Btw, if you are going to ask your users to set a GHC_HOME environment variable, then why use this library at all in the first place? Well, during development and for running unit tests it is convenient to not have to set any configuration, so using ghc-paths is good, but then it would be nice if the same binary would also transparently and automatically be portable via an environment variable setting.
Thank you
The text was updated successfully, but these errors were encountered:
The problem with this library is that it bakes the absolute path of the GHC installation into the compiled binary, but then if the binary is copied to another computer, the GHC installation might be in a different path and the binary won't work.
I propose that this library should transparently read from an environment variable called
GHC_HOME
first, if it exists then use that, otherwise fallback to the compiled-in path.Other languages have a similar environment variable, for example:
JAVA_HOME
andPYTHONHOME
.The current workaround is to simply write the code yourself to read from
GHC_HOME
environment var and then fallback toghc-paths
, but having the code in this library would help to standardize my proposedGHC_HOME
environment variable throughout the Haskell ecosystem.Btw, if you are going to ask your users to set a GHC_HOME environment variable, then why use this library at all in the first place? Well, during development and for running unit tests it is convenient to not have to set any configuration, so using
ghc-paths
is good, but then it would be nice if the same binary would also transparently and automatically be portable via an environment variable setting.Thank you
The text was updated successfully, but these errors were encountered: