Shep as a library

[chris-olszewski]

I think we're pretty close to this being a thing. Just a matter of making sure all the functions return something/can be used without their respective commands being run first.

[chris-olszewski]

Would also probably make sense to make all calls to shep as a library be quiet by default

[chris-olszewski]

So a few things that I think are still a bit up in the air:

• Where should documentation for the pragmatic interface live? (Also how to generate it)
• There are some commands that don't translate well to being used in a library:
  • run as if there are errors it calls process.exit(numOfErrors) -> should be moved to command file
  • logs as it returns a chain of promises that continue to grow until the process is stopped -> streams?
• Some commands don't have a clear idea of what they should return:
  • new
  • deploy
  • build
  • generate functions

[chris-olszewski]

As part of this I feel like we should try to remove listr calls from the functions themselves. Big issue with this is shep.deploy as listr is actually relied on by deploy for control flow

[southpolesteve]

What if the commands accept a `listr` or even more generic `logger` instance that can be updated as it proceeds? If not provided it can do nothing.

…

On Fri, Jun 16, 2017 at 4:09 PM, Chris Olszewski ***@***.***> wrote: As part of this I feel like we should try to remove listr calls from the functions themselves. Big issue with this is shep.deploy as listr is actually relied on by deploy for control flow — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#258 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcxaOBIdmg4tRdGMbeDzoldaty2-LYxks5sEoyFgaJpZM4N7OTw> .