I want to share my take on the httpie versus CLI question. Overall I think the CLI should only support workflows and here's why. When the user is providing the data, httpie provides a great tool for that data to be input either via args (just like a cli) or via json snippets. The hallmark of this usage is that the user already knows the data and can easily form a httpie call with CLI args, or the json data file. User's don't have to be a "programmer" to do this. The tool already exists.
Contrast that httpie usage against a "workflow" tool. The hallmark of the workflow tool is that it's using data from one response and feeding it into the next or a future call. Without a workflow tool, for a non-programmer user, parsing a response and then feeding it into a future call will always be a manual, errorprone, copy-pasta process. I think this is where the sweet spot is for the CLI; it's for non-programmer-users, who would need to take response data and feed it back into future calls which is hard for them. So for ^ reasoning I'm lead to these conclusions: (1) that the CLI does no "single call" operations. Those are already handled veyr well by httpie. (2) I believe I'm +1 to not releasing Pulp3 with a CLI because I think that would allow us to avoid guessing at requirements. If we wait a bit, the users will declare what they want very clearly. On Sat, May 19, 2018 at 1:31 PM, David Davis <[email protected]> wrote: > Let me ask: could we ship the MVP with just a REST API? I don’t see any > Pulp users clamoring at this point for a CLI or WebUI. It sounds like we > are maybe trying to solve a problem that doesn’t exist at this point. > > Maybe we can focus on getting the MVP shipped. Then we can get feedback > from the community as to what sorts of UIs and UI features they’d like to > see. > > > David > > On Sat, May 19, 2018 at 11:54 AM, Dennis Kliban <[email protected]> > wrote: > >> On Fri, May 18, 2018 at 3:54 PM, Dana Walker <[email protected]> wrote: >> >>> >>>> The pulp-admin CLI provided value not because it combined things but >>>> because it managed auth and reduced syntax complexity. >>>> >>> >>> Here's a (perhaps naive, please humor me) question--does it reduce >>> syntax complexity enough over httpie to bother with at all? Now that we >>> have a Django app, would most users either a) be comfortable enough with >>> the REST API or b) prefer to see an actual Django web UI instead of the CLI? >>> >>> >> Most users of the CLI would probably prefer a UI. In situations where the >> UI is limiting the interaction possibilities, the user would probably >> prefer to use the REST API directly or via bindings for the language of >> their choice. >> >> With that in mind, I think it is worth exploring adding the Django >> Admin[0] site to Pulp. We could perform just a little bit of configuration >> and expose all the models we are interested in exposing. The hard part >> would creating templates for the sync and publish workflows. >> >> [0] https://docs.djangoproject.com/en/2.0/ref/contrib/admin/ >> >> >>> Just curious about the typical users. >>> >>> Dana Walker >>> >>> Associate Software Engineer >>> >>> Red Hat >>> >>> <https://www.redhat.com> >>> <https://red.ht/sig> >>> >>> On Fri, May 18, 2018 at 1:30 PM, Jeff Ortel <[email protected]> wrote: >>> >>>> The main goal of the CLI is to make it easier (than using the REST API >>>> and http) for admins to perform routine tasks. It seems likely that A >>>> CLI *could* provide an improvement by reducing the REST syntax >>>> complexity without combining the steps to complete a task. Also, I think >>>> we should consider the frequency of tasks & steps. For example: I would >>>> anticipate that work flows involving creating and deleting of repositories, >>>> remotes, publishers and distributions are performed with relatively low >>>> frequency. And, each of those will likely happen with different >>>> frequency. Work flows involving sync & publish would be performed with >>>> relatively high frequency. Updating resources (perhaps except >>>> Distribution) don't seem likely to be a regular thing. >>>> >>>> My point is: I think that providing high level, task oriented, >>>> combination CLI commands won't provide enough value to justify the effort. >>>> An admin running (1) complex command (think pulp-admin) rather than 3-4 >>>> simple commands does not seem like an improvement. Especially since the >>>> CLI would probably need to provide the simple commands a well for work >>>> flows not accounted for. For example: Edit a remote. Or, would the admin >>>> need to use the REST API for that? >>>> >>>> The pulp-admin CLI provided value not because it combined things but >>>> because it managed auth and reduced syntax complexity. >>>> >>>> >>>> On 05/17/2018 10:52 AM, Dennis Kliban wrote: >>>> >>>> The use cases we outlined earlier provide very little value over using >>>> httpie to interact with the REST API directly. I'd like to propose 5 new >>>> use cases: >>>> >>>> - As a CLI user, I can create a repository, a remote, a publisher, >>>> and a distribution with a single command. >>>> - As a CLI user, I can create a repository version, a publication, >>>> and update the distribution with a single command. >>>> - As a CLI user, I can list remote types available on the Pulp >>>> server. >>>> - As a CLI user, I can list publisher types available on the Pulp >>>> server. >>>> - As a CLI user, I can list all repositories available on the Pulp >>>> server. >>>> >>>> >>>> The use cases proposed at the beginning on this thread require the user >>>> to perform 4 steps before any content can be synced: >>>> >>>> 1) Create repository >>>> 2) Create remote >>>> 3) Create publisher >>>> 4) Create distribution >>>> >>>> The goal for the CLI should be to reduce this to a single step. The CLI >>>> will need to make some assumptions for the user: publisher name, >>>> distribution name, auto publish, auto distribute, and maybe others. >>>> However, this will allow the user to use a single command to create a >>>> repository that's ready for sync/publish. >>>> >>>> Sync/Publish/Distribute workflow can also be 3 steps: >>>> >>>> 1) Create a new repository version >>>> 2) Create a new publication >>>> 3) Update distribution >>>> >>>> The goal here is to also reduce this to a single step. >>>> >>>> The other use cases are auxiliary. >>>> >>>> Questions? Thoughts? Ideas? >>>> >>>> -Dennis >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, May 14, 2018 at 11:58 AM, Dana Walker <[email protected]> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> Dana Walker >>>>> >>>>> Associate Software Engineer >>>>> >>>>> Red Hat >>>>> >>>>> <https://www.redhat.com> >>>>> <https://red.ht/sig> >>>>> >>>>> On Tue, May 8, 2018 at 10:31 AM, Jeremy Audet <[email protected]> >>>>> wrote: >>>>> >>>>>> A configuration file in the user's home dir, right? >>>>>>>> >>>>>>> >>>>>>> Yes, exactly. >>>>>>> >>>>>> >>>>>> Can we make sure to avoid placing configuration files directly in >>>>>> users home directories, and instead place them into directories like >>>>>> ~/.config? This is in line with the XDG Base Directory Specification >>>>>> <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>. >>>>>> The spec is pretty straightforward, but Pulp Smash uses pyxdg >>>>>> <https://www.freedesktop.org/wiki/Software/pyxdg/> to avoid >>>>>> mistakes. There's two big benefits to doing this: >>>>>> >>>>>> - Less clutter in home directories. >>>>>> - Guidance on what to do with other types of files, such as >>>>>> cached files and runtime files. >>>>>> >>>>>> Projects such as git, htop, lftp, mpd, neovim, tmuxinator, boybo, and >>>>>> more do this. >>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing >>>> [email protected]https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
