# CLI Team
* Untriaged: https://github.com/pulp/pulp-cli/issues?q=is%3Aissue+is%3Aopen+-label%3Atriaged
## Pending action items
* Feature gap matrix
* Feature, endpoint, plugin, implemented?, implementable?, priority
* documentation push (see 7-Jul minutes)
* mdellweg talk with packaging folks about requested requirements
## Feature Gaps
* content commands
* ansible +1
* rpm +1
* pulp import +1
* remote_href param (sync) +1
## Oct, 27
* different content is different (rpm) so it may need to go into different command groups
* polymorphy around the "--type" parameter looks like a mess
* AI: ggainey to do POC of a different approach by next mtg
* Pulp shell would be super useful if you could `cd` into a context
* also capturing output for further processing would be nice
* Yay feature matrix
* Please comment on the format
## Oct, 13
* Squeezer is currently built on the premise that it has no external dependencies, but reusing the openapi.py between the two projects may bring a lot of maintenance benefit. What would be the impact of having the squeezer collection depend on pulp-cli?
* This may need more thinking about impacts.
* No timeline for a change like this.
* Should we rename the base branch to main?
* Let's do this for consistency
* [mdellweg] to change the name. Done.
## Sep 29
* Reviewers: Please make sure every new user facing string gets a `_()`.
* Also we should gradually fix all the others we stumble over.
* State of the translation experiment
* We are currently testing the CLI with pulpcore 3.11 - 3.15. Are we ready to drop any workarounds for <=3.10 ?
* Should we also install a global `needs_plugin("core", "3.11")` so users are aware and may use older versions?
* make sure we can at least update the cached-schema if current is "too old" to run the command
* the only significant potential consumer of pulp-cli pre-core-3.11 is Sat6.9, which is using core-3.7.
* the current pulp-cli functionality serves that need just fine
* +1 for 0.12 advancing the pulpcore requirement to 3.11+
* If needed desperately, we could make a 0.11 branch that even runs it's CI with core-3.7 as a target and accept backport PRs
* OSTree support - prob wants/needs to be its own package
* see the current (incomplete) state of deb-support for an example
* need an oci-image that includes 'external' plugins for testing
## Sep 15
* Nightly test is failing
* this is failing for async orm incompatibilities
* Should start working again with https://github.com/pulp/pulpcore/pull/1622
* container rebuild has been triggered
* Where to add ostree support?
* No strong opinions
* pulp_deb would like to see another external plugin
* To improve support of external plugins
## Sep 1
* Certguard plugin
* should certguard commands be separate from core package?
* how to deal with commands placement
* pulp content-guard rbac ... +1 +1+1
* pulp cert-guard -t rhsm ...
* 3 month planning in 2 weeks
* some FTEs may be freed up - do we want to raise cli-prio?
* content for rpm/ansible?
* ggainey AI - submit PR to generalize string/@ behavior
* filtering (for existing cmds) would be good
* field-selectivity can wait since you can be selective w/ jq after the fact
## Aug 19
* Introduction to quba42
* transfer of the repo to pulp namespace; adding the pulp/debian team
* [mdellweg, davidd]
* upload to PyPi; add quba42 to that package
* pulp_rpm workflow docs still use httpie
* a good candidate for docs-day
* same for pulp_container
* Docs day
* General organization (structure, outline); probably before docs day
* Get the user started; point to workflow docs
* dev-user-hat needs "pip install -e ."
* pip-comfortable user needs pip-install
* rpm-comfortable user needs to know how to dnf-install
* Improve "how to add commands"
* Reminder: self-assign issues or check issue assignment
* unassignment _is_ possible
* check that github correctly links PR and issue
* assign issues to next-milestone please?
* can we do this as part of the merge-workflow?
## Aug 04
* Time slot for this meeting
* We get into conflicts quite often; can we move this meeting to a more stable slot?
* Feature gaps (e.g. lack of content commands) are problematic
* How do we proceed?
## July 21
* We need to rethink dependency version pinning
### July 07
* ~~0.10.0 please!~~
* ~~preferably on new-click-shell/click-8~~
* ~~where are we wrt package-namespace issue?~~
* done - rpms are built!
* Evgeni++ !!!
* Gave Grant the button to force merge
* Also added gerrod to the cli team
* [david] set up templates for Github Issues
* we need a documentationm push, badly
* redo workflows using CLI examples
* better user-docs for CLI
* create feature-gap matrix to help community drive priorities (give to Mel?)
### June 23
* Github Issue templates https://github.com/pulp/pulp-cli/issues/templates/edit
* Offers some neat features like automatically assign labels
* mypy (0.900) changed the policy that you need to install typing packages explicitly
* The shipped typing package for click (7.1.2) seems to be missing some types
* click-shell still doesn't support click 8
* Use community fork https://github.com/clarkperkins/click-shell/issues/30#issuecomment-864613900
### June 9, 2021
* Packaging on Rhel/Centos 7 may not work with namespaced packages
* Maybe we cannot use namespaced packages
### May 26, 2021
* click 8
* we are not yet there
* waiting on https://github.com/clarkperkins/click-shell/pull/31
* bash completion stops working
* daviddavis to file a click-8 issue
* mypy linting is hard to impossible to fix for 7 and 8 simultaneously
* Evgeni has reported strange problems with old setuptools
* They struggle hard with namespace packages
* I would love to get some final review on this:
* I want to base capabilities (primarily for pie code) on it
* mkdocs, publish them to docs.pulpproject.org?
### May 12, 2021
* Click 8 (just released) breaks click_shell
* We decided to pin all dependencies to major versions at least
* and cut a release with it
* Look at bats
* Eric mentioned that in the Katello world the cli should be used with caution for any non-read-only operation
* We could add a flag that asks for confirmation
* Katello could configure the dry-run option
* we may need to add `--no-dry-run` acutally as `--force`
* [x9c4] Make a PR
### April 28, 2021
* Should we support plugin schema api changes?
* We are doing it with `has_plugin`
### April 15, 2021
* Release 0.8.0
* Moving items to 0.9.0 milestone
### March 31, 2021
* We plan to create a feature gap matrix
* Feature, endpoint, plugin, implemented?, implementable?, priority
* Discuss (asynchronously) a release date for 0.8.0 next wednesday
* [mdellweg] start the thread
### March 17, 2021
* Better classification of options
* I realized, we have three different types of options referring to objects:
* filter options (used for list_command)
* lookup options (used for show, update, destroy)
* resource options (used in update, create, sync, ... to reference other options)
* I see some potential for each of them to make the actual command definition even more descriptive than today.
* Easier command chaining/sequences
* Common workflows produce an href that needs to be manually copied to be inspected or used in other commands. (publish, sync)
* Suggestion: have Pulp context store output of previous command and have it be referencable through new resource language
* `pulp file publication create --repository foo`
* `pulp file distribution create --publication p:href ...`
* `pulp -b file repository sync --name foo`
* `pulp task show --href p:task`
* Reference language could use it's context features to have common shorthands, aka p:pulp_href == p:href, p:latest_version_href == p:latest
* This would need a notion of a session
* Maybe we can implement a pulp-shell
### March 3, 2021
* 3 month planning - March 17
* complete RPM and container commands
* install CLI in pulp_installer dev boxes
* [daviddavis] file against the installer
### February 17, 2021
* Tracking Katello issues?
* GH Labels it is [x9c4]
* How do we reference objects (like repos on a publication, or an exporter)?
* We should have a common language
* There must be a way to specify the object plugin and type
* If the name has colons: `::name:with:colons`
* use --repository-href
* Are there forbidden characters for the name, we can use?
* Migration support - https://github.com/pulp/pulp-cli/pull/142
* We do not have the migration_plugin in the container
* This is skipped in all CI tests
* Should we separate it and run tests in a special way?
* separating is good if someone wants to own it
* It allows for separate installation
* Do we want to use vcrpy to tests with prerecorded server communication?
* Can we test it at least nightly in the migration_plugin CI?
* Try this [daviddavis]
* [x9c4] Im happy to merge based on code review.
* We are in `_`-land
* We need to find a way to support translations for plugins
* I intend to build extensive Makefile tooling for message extraction and catalog compilation
### Feb 3, 2021
* open PR's - https://github.com/pulp/pulp-cli/pulls
* Command Structure
* Do we want interspersed arguments (e.g. lookup parameters before the action to perform) (Our current technology should allow both)
`pulp <settings> file repository -t file --name foo show`
`pulp <settings> file repository -t file --name foo update --name bar --description "renamed"`
`pulp <settings> file repository -t file --href p/a/v3/repositories/file/file/<uuid>/ version --number 2 show`
* this means the name-or-href lookup question will be handled in one place for each resource type
* the "same" option can be used for different purposes (lookup vs. payload)
* commands for a repository and it's versions start the same way
* It can be confusing to know where an option needs to go
* Would it be possible for help screens to show all missing options and where they go?
* For example, if I run `pulp file repository show --help` it can show me `--name` and btwn `repository` and `show`
* collect all parameters at the end (all but settings and type)
`pulp <settings> file repository -t file show --name foo`
`pulp <settings> file repository -t file update --name foo --description "cannot be renamed"`
`pulp <settings> file repository -t file update --name foo --new-name bar --description "renamed"`
`pulp <settings> file repository -t file repository version show --repository-href p/a/v3/repositories/file/file/<uuid>/ --number 2`
* may be more intuitive
* consistent with pulp-admin (pulp 2) and hammer
* renaming things will become harder this way
* What does it mean to change the 'natural key' (eg, 'name') of an entity?
* AI: Choose Option 2, send email to list describing what we're doing and why and ask for feedback, revisit in a month
* pulp-cli project on redmine - archive?
* Issues will not be accessible
* AI: daviddavis to archive, fix changelog links to not-point to plan.io anymore
* 0.3.0 release
* AI: daviddavis to release this week or next
* AI: x9c4 Yes please! at least get us into _() land
### Jan 20, 2021
* open PR's - https://github.com/pulp/pulp-cli/pulls
* How do we track issues?
* separate project (current: https://pulp.plan.io/projects/pulp-cli)
* add a query to the projects to see the issues
* category in pulpcore
* category in every plugin (including pulpcore)
* Being the first to move to GHI +1 +1
* daviddavis to do the move
* Plugin bootstrapping?
* video demo (see ggainey)
* Lazy evaluation (WIP)
* the goal is to be able to access all help screens with no access to any server
* [AI] please comment on the design
* User reported feature - https://pulp.plan.io/issues/8120
* This needs some design work around the question "How do we specify a lot of content?". [AI] Please comment on the ticket.
### Jan 6, 2021
* We need a release process +1
* Release on regular basis
* Add changelog/towncrier
* Do a manual release (0.1), note each step. Then automate.
* Create changelog
* tag commit
* build and push to pypi
* Which pulpcore releases should we support?
* Starting with 3.9, support 5 y releases back
* Follow LTS discussion and adjust based on decision
* Some resources can only be fetched by name but they are sometimes returned as hrefs (eg created_resources)
* Add an --href (or id?) option to commands that take name
* Command needs to validate that the href matches the resource
* [daviddavis] file a task
* Add a pulp show command that takes an href
* Next goals? Anything to discuss before 3 month planning?
* user-management? needs user-REST first
* [david] email that developers need to file CLI tasks as they add features
* pulp_ansible support - offer to gerrod
* Satellite wants
* Valid request
* This is probably not possible with the REST api atm
### Nov-12, 2020
Context: reviewing [PR#27](https://github.com/pulp/pulp-cli/pull/27/)
Attendees: ggainey, x9c4
* Context classes wrap the api for specific resources
* dictionary in common, 'type': ContextClass
* see file/repository.py:126, remote-access - would be redirected thru the ContextClass-by-type
* plugins would register their contextclasses as part of initialization
* add feature-flags to context - eg, "this repository type knows how to be exported'
* allow for more general code-paths
* Container has multiple repo-types - so it's the first more-complicated entity
* debian has multiple publisher-types
* discussion RE make_pass_decorators added in PR#27
* removes some of the boilerplate into decorators and signature instead of code - /me cheers wildly!
* every subcommand has a Context, every Context has/can have an object
* what about plugins we don't maintain?
* how to give comunity members the ability to extend without being dependent on 'us'?
* hybrid approach - 'we' ship lots of support, but can be 'plugged' from outside
* see setup.py L18-19 for current pluggability
* get ggainey merge-access to pulp-cli (x9c4 to ask daviddavis)
* next steps
* container-PR is refactoring a lot w/out breaking current interface
* let's do the generalized-context-dictionary PR next
* THEN refactor exporter/export to use ^^
* would be really handy to have a --dryrun flag - spit out the actual pulp-REST-calls but don't do them
* prob need to do the read-only calls to look things up - would not execute the 'unsafe' (PUT/POST/DELETE/PATCH)
### Nov 4, 2020
* pulp_migration support?
* No plans to support the migration plugin
* User stories
* Not really helpful ATM. Write them if you need them.
* Dealing with lint/checks
* mypy and shellcheck are picky and require ramp up
* Factor extra time into estimates
* What we have so far
* Most pulp_file commands
* No content commands
* Lots of missing options (eg filters) and no help text
* Orphan cleanup
* Stuff to do
* Help text
* Another plugin (rpm or container)
* ggainey to demo creating a cli command from scratch
* Possible mypy demo?
* Help text
* Can we grab it from the schema?
* david to file ticket (https://pulp.plan.io/issues/7787)
### Oct 22, 2020
* Recorded talk?
* How to write a CLI command
* AI: ggainey to work on exporter commands and create presentation based on this work
* Timeframe: before end of November
* Adding type annotations
* [david] will review and merge
* Settings feature has been merged
* Planning for next quarter?
* Create a 0.1.0 release milestone in redmine?
* for next quarter:
* happy/main path through pulp_rpm
* ddavis to write up user-stories. meet to discuss planning in mid/late november
* can we log the actual API calls?
### Oct 8, 2020
* Handling SSL
* https://pulp.plan.io/issues/7658 - turn off ssl verification (fixed)
* https://pulp.plan.io/issues/7652 - need to handle eventually
* Run CI every night?
* Let's run 7 days a week for now
* Our first bug!
* Possible explanation: client is making a http request and being redirected to https and then does a GET request
* x9c4 to investigate
* Blog post and mailing list announcement are live
* Planning for next quarter (Dec-March)
* We'd like to have a usable CLI by spring. Get upstream feedback and for our personal use.
* What goals do we have?
* Easy to install/packaged
* Covers pulpcore and pulp_file
* pulp_rpm happy path (sync, publish, distribute, upload)
* How much time do we want to ask for?
* 3.5 FTEs
* Hard requirement: new features require a demo
* let's allow to use the cli to demo new features to get early contributions +1
* Meet again in 2 weeks after 3.8 release
### Sept 23, 2020
* [david] Finish CLI PoC and upload to asciinema
* Send out email to pulp-list about PoC?
* Include asciinema
* How to install, use CLI
* Ask for feedback
* Contact mcorr first and see what she recommends
* Should we meet regularly?
* Meet again in two weeks
* Hopefully have some user feedback
* We need a decision about where to have the cli code
* it's not urgent.
* for now, keep using a single repo
* Supporting multiple versions of pulpcore and plugins
* For now, use conditional statements when needed
* Versioning of the CLI
* Needs more thought
###### tags: `CLI`