stackbuilders
`loadFile` return value
Hi there, I maintain purescript-dotenv which is essentially a direct port of this library (albeit a bit dated at this point). I have had an eye on the loadFile return value for some time now, wondering whether it is truly what my clients expect.
On one hand, a MonadIO m => m () return type would imply that loadFile is a procedure with no meaningful return value. Clearly the next step would be to use lookupEnv, getEnvironment, etc., to retrieve value(s) from the (modified) environment.
On the other hand, MonadIO m => m [(String, String)], the current return type, could imply that this is a more of an effectful "read" action than one which actually makes changes to the environment. Regardless, if I want to use the return value, I might incorrectly assume that it includes the full environment (i.e. that which getEnvironment would return) rather than the subset that was added from the .env file.
I am not necessarily suggesting a change or that the current design is at all "incorrect", but I would be interested to understand why only a subset of the environment is included in the return value. Was it just an arbitrary decision, or is there a specific use case where this makes sense?
Thanks in advance for any thoughts you can share as well as for making this excellent library available to the community.
Hello @nsaunders Thanks for your question and I'm sorry for this late reply. I went through the commits and I noticed we started with the idea to return unit m () but later we changed it to incorporate a new feature (I assume for convenience) that we ended up removing from this library. IMHO, I prefer to go with the initial approach. In fact, we suggest users to ignore those results (void $ loadFile ...). We also expose parseFile in case someone wants to read the envs from a .env file, so I don't thing we should return the envs from loadFile. I'll change the interface to look as it was before.
Thanks for bringing that to our attention. 😄
Thanks for your response @CristhianMotoche. For what it's worth, I think the change you are suggesting will remove some ambiguity, and I will plan to follow suit in my own project.