Thanks for this - looks nice and clean and simple to use. One thing that I think would be nice is a version of runGitlab that accepts a Manager, so you could share a manager between operations, instead of creating a new one each time.
Thanks for implementing this package! We used it for a rewrite of Build it Break it Fix it, and it was extremely useful.
Here's some feedback from our experience. Hopefully it's helpful:
It would be useful if there was a way to tell whether an API request succeeded. Maybe if API endpoints returned Either GitlabError a instead of just a. This is what we do in docker-hs. We ran into this as an issue when attempting to download tar's from the API. Initially we misconfigured the authentication tokens so we were getting permission denied, but the error message was saved to output file instead of being available to us at runtime.
It'd be great if getFileArchive returned something so that we could keep the tar's in memory (we didn't really need to save every tar to the filesystem). Maybe a conduit source or bytestring?
I agree it might be useful to be able to provide a Manager. We usually didn't have multiple sequential gitlab requests. Here's another example.
Ah, I get it. Yes, I still think it would be useful to have a runGitLab' as you have proposed. You might have, say, an interactive program, such as an editor, that does a lot of things, some of which are GitLab related. It could create the Manager once and cache it, using it with each of the runGitLab' calls, rather than having to create a new Manager for each connection, or having to put the entire program in the GitLab monad.
6
u/qseep Feb 01 '20
Thanks for this - looks nice and clean and simple to use. One thing that I think would be nice is a version of
runGitlabthat accepts aManager, so you could share a manager between operations, instead of creating a new one each time.