> that the CLI does no "single call" operations. Those are already handled veyr well by httpie.
If a user wants for example to update an object (repo/remote/distribution/etc), then they have to switch from the CLI to httpie? David On Mon, May 21, 2018 at 9:43 AM, Brian Bouterse <bbout...@redhat.com> wrote: > 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 <davidda...@redhat.com> > 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 <dkli...@redhat.com> >> wrote: >> >>> On Fri, May 18, 2018 at 3:54 PM, Dana Walker <dawal...@redhat.com> >>> 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 <jor...@redhat.com> 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 <dawal...@redhat.com> >>>>> 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 <jau...@redhat.com> >>>>>> 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 >>>>>>> Pulp-dev@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> Pulp-dev@redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing >>>>> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev