On Thu, May 17, 2018 at 8:14 PM, David Davis <[email protected]> wrote:
> Overall, I am hesitant to start with complex CLI commands. Instead I had > hoped to start with basic, auto-generated CLI commands which we could then > build off to add more complex commands in the future. > +1 ideally the CLI would provide some "mutable, high-level combinations" of the basic CLI commands later on e.g by giving the user macros they could reassemble on the CLI; considering the lisp-like Hylang[1][2][3] as an example macro language: $ pulp-admin --eval '(create (repo-by-url foo http://zoo.repo/ ))' {'repo': {'remote': {'name': 'zoo-remote', 'id': 1, 'url': ' http://zoo.repo'}, 'name': 'foo', 'id': 1} could as well be specified by: $ pulp-admin --eval '(create (remote [[name hy_zoo] [url http://zoo.repo/]]))' {'remote': {'name': 'Hy_zoo', 'url': 'http://zoo.repo', 'id': 2}} $ pulp-admin --eval '(create (repo [[name foo] [remote_id 2]]))' {'repo': {'remote': {'name': 'Hy_zoo', 'url': 'http://zoo.repo', 'id': 2}, 'name': 'foo', 'id': 2}} or equally by: $ pulp-admin --eval '(create (repo [[name foo]] {'remote' {'name' 'Hy_zoo' 'url' 'http://zoo.repo' 'id' 3}}))' {'repo': {'remote': {'name': 'Hy_zoo', 'url': 'http://zoo.repo', 'id': 3}, 'name': 'foo', 'id': 3}} or as well by: pulp-admin --eval '((->) (create (remote [[name Hy_zoo] [url http://zoo.repo]]) (create (repo [name foo] ))' so that the user is in control of the process rather than the converse ;) -- milan [1] http://docs.hylang.org/en/stable/index.html [2] http://docs.hylang.org/en/stable/tutorial.html#macros [3] http://docs.hylang.org/en/stable/tutorial.html#protips PS: I'm not totally Hy right now ;) > Questions/responses inline though. > > On Thu, May 17, 2018 at 11:52 AM, Dennis Kliban <[email protected]> wr > ote: > >> The use cases we outlined earlier provide very little value over using >> httpie to interact with the REST API directly. >> > > I think this may be true for the first iteration of the CLI, but > successive iterations will handle more complex use cases. > > >> 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. >> >> How would users do things like update objects? Like what if I want to > edit the URL I am syncing a repo from? > > >> >> 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. >> > > I think this is very brittle given the mutability of object names. Users > couldn’t use both the CLI and REST API. They’d have to pick or choose or > else run the risk of disconnecting objects. > +1; we'd have to assume certain object name "shapes" such as 'repository-{name}'.format(name='foo') > > Also, how do we support things in the future like multiple remotes for a > repo or shared remotes between repos? > > +1 > >> 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 >> >> >> >> >> > A couple more questions: > > How would we handle things in the future that are plugin-specific like > content upload/creation? > > Also, would this CLI use auto-generation at all? Or would it rely entirely > on custom code? I assume the latter which means this would be similar to > the Pulp 2 CLI in which every new API change required a change to the CLI > code. > > > David > > On Thu, May 17, 2018 at 11:52 AM, Dennis Kliban <[email protected]> > 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 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
