Open MartinSStewart opened 4 years ago
I think the functionality could certainly be useful, but I have a few comments/questions:
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.)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?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?
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.
Directory
to a specific package using the Elm.Package.Name
and Elm.Version.Version
types provided in elm/project-metadata-utils
.
I think the following would be a useful helper function to have once https://github.com/ianmackenzie/elm-script/issues/21 is solved.
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"