Add Script.Environment.elmHome

[MartinSStewart]

I think the following would be a useful helper function to have once https://github.com/ianmackenzie/elm-script/issues/21 is solved.

elmHome : Script.Init -> String
elmHome init =
    let
        default =
            case init.platform of
                Script.Platform.Posix _ ->
                    "~/.elm/"

                Script.Platform.Windows ->
                    "%appdata%/elm/"
    in
    Script.Environment.get "ELM_HOME" init.environment |> Maybe.withDefault default

That said, I'm not sure if it's expected for filepaths to have a trailing / or not. It might be better if there was a Path datastructure exposed that would let you safely create and combine paths without risking getting something like "~/.elm/" ++ "/test" == "~/.elm//test"

[ianmackenzie]

I think the functionality could certainly be useful, but I have a few comments/questions:

• I'd be inclined to have it return a Directory, not a String. (There is a Path data type internally, but I like the security model of File and Directory values and I'd prefer to avoid the complexities of cross-platform path manipulation if possible.)
• Assuming it returned a Directory, are there valid arguments for returning a Directory Writable or should it be a Directory ReadOnly? What specifically were you thinking of using it for?
• Does this make sense to include in the core elm-script, or would it eventually make sense as a separate library/package? For example elm/project-metadata-utils exists as a separate package. While right now there isn't an easy way to share elm-script-based packages, it might make sense to have the function under a separate module (e.g. Elm.PackageCache.directory or Elm.Packages.directory) so that it can be more easily split out later.

Thoughts?

[MartinSStewart]

• Returning Directory seems reasonable. A path doesn't tell the user if what they are dealing with is a file or directory.

• It should be Directory ReadOnly. The documentation here specifically says

do not modify or add files in ELM_HOME for your work

My use case is collecting packages licenses used in a project at work.

• Yeah, maybe it makes more sense to have a separate package for it. Then more specialized functions could be provided for getting the Directory to a specific package using the Elm.Package.Name and Elm.Version.Version types provided in elm/project-metadata-utils.