CLI Team

"Interesting" branches

  • 0.14 (katello packaged)
  • 0.21 (katello packaged)
  • 0.23 (katello packaged)
  • 0.29 (katello packaged)
  • 0.30
  • 0.32 (current release)

Pending action items

Agenda

  • [ON HOLD] For discussion: should we be at 1.0 now?
    • let's not until import/export rework is merged
      • not yet - deadlock investigation intervened

2025

April 9

  • Need to plan PRN work.
  • Discussion about cli plugin packages in fedora.
    • Idea: Bundle them in the original package.
      • Pro: Less maintenance, no package onboarding needed.
  • Update "interesting branches".

March 12

  • Review supported workflows docs.

Jan 29

  • We want an upper bound test
    • in response to 'packaging' CalVer issue
    • would keep us from merging dep-changes that are actually not installable
    • let's do!
    • pto and cfgmgt camp are happening - if nobody works on this by nxt mtg, then make it an actual AI at that point
  • Squeezer is now fully based on pulp-glue!!
    • should squeezer be discussed here? - yes, makes the most sense
    • it is "in use" upstream
    • so are we really the "client tools/integration" meeting?

Jan 15

  • Happy New Year!
  • Let's get a 0.30 released today
    • last new release was in September
  • discussion RE "would be great to have cli installed/installable on the downstream products"
    • would get more use of the CLI, and make life easier for suppot and us
  • discussion: squeezer bug found/fixed
  • discussion: pulp-glue and aiohttp
    • Would Be Nice - when we have time. In, like, 2026
    • there are some Implications (around sessions and keep alive) w/ trying to do async calls from a synchronous context - will need some thought/investigation/experimentation

2024

Jul 31

  • DONE [mdellweg] get 0.27 out
  • DONE [ggainey] work w/ ppessoa to punt stale changelog file from pp.org
    • working w/ #pulp-infra to figure out best approach for the problem
  • oci images fail on rpm copy
    • https://github.com/pulp/pulp-cli/pull/1027
    • let's get this released to 0.27.N and see howthe image-publishing goes tonight
    • discussion RE the "Copy OID problem" ensues
      • rpm/deb/ansible all collide on same OID for advanced copy
      • this is A Problem
      • fixing it will destabilize bindings-users
      • what's the best way way to fix this?
      • NOTE: this is not a CLI-Thing - needs to be raised to the larger team. Monday team mtg?
      • NOTE: "DO NOT 'pollute' the global namespace" should def be documented as A Rule for plugin-authors (also not a CLI Thing)

Jul 17

Jul 3

  • https://github.com/pulp/pulp-cli/issues/994
    • should I combine the two POC PRs (1000 and 1003) to give the user the option to choose "one atomic new version" vs "version per upload"?
    • let's add two flags
      • create-tmp-repo
      • publish-at-end
  • Responsibility for Squeezer.
    • this is the obvious team to support squeezer/glue
    • should have the pulp-cli group
  • [decko] OAuth2 support - https://pastebin.com/DkxgUbkw
    • what are the next steps to make this "official"?
    • takes advantage of core's ability to add auth-services as a setting
    • there's a hook in the AuthBase to deal with reauthenticating on fail
    • needs a requests-compatible subclass - the POC above doesn't implement the whole flow yet (handle401)
    • what's the right way for the CLI to prioritize which auth-process should be used in the face of a server that allows multiple auth workflows?
      • proposal: CLI is opinionated about auth-preferences, and tries them in order based on provided client-info
    • question: how to deal w/ pulp-service that provides multiple of the "same" security scheme
      • first cut is "cli will do what it can, and if your backend is too complicated we may not be able to auth correctly"
    • concern: providing tests for this is Complicated
      • requires pulp-backend using OAuth2?
      • test against oauth test systems "directly"?
      • have the same problem with cert-auth (and lack-of-tests has already caused us a regression once)
      • maybe look into Services-CI adding tests for this functionality

June 5

  • Discussion about supported workflow coverage
    • pulp debug openapi operation-ids tells you all the id's.
    • We could intercept PulpContext.call and report all the "used" id's in the tests.
    • That comparison should give us a broad overview.

May 8

  • looks like plugins all support 0.25 now

Apr 10

  • docs updates in progress
  • discuss what pulpcore branches do we support/want to support/need to support
    • Sat-6.12 : core/3.18
    • Sat-6.13 : core/3.21
    • Sat-6.14 : core/3.22
    • Sat-6.15 : core/3.39
    • katello/4.13 : core/3.49
    • We want to add 3.49 to the test matrix.
    • We decided to drop 3.21 for it.

Feb 28

  • Convert to new docs-stack - 903
    • who wants to take this?
    • should glue continue "under" cli, or be in its own namespace?
      • glue docs are mostly auto-generated API docs currently
      • glue is, otoh, used "on its own" in a number of places
      • consensus: pulp-glue wants to be its own subsection
      • cli-arch-doc is already about half pulp-glue
      • versioning?
        • not in Phase 1 - maybe later
      • do we want to just link files?
        • we can, butwhy?
      • "new docs" is The Place to make changes/additions going forward
      • AI: pedro is going to submit PRs
  • discussion about supported-branches
    • let's leave things where we are

Feb 14

Jan 31

Jan 17

  • discussion on some Unintened Consequences of moving away from setuptools et al
  • Do we need a "plugin template"? What should it manage?
  • https://github.com/pulp/pulp-cli/issues/821
    • Possible solutions:
      • Don't put the pwd in a cfg-file - enter on every line :)
      • teach pulp-cli to require o-rw access on cfg-file or refuse to run
        • like ssh files
      • Pulp should provide api tokens.
        • Maybe with limited access.
        • CLI: pulp login requests and stores a token.
        • Tokens can be time limited.
      • Pulp-cli can implement an interface to DBUS secret service.
      • could take advantage of server-side sessions, and keep a "cookie jar" around to store them
        • pulp-cli would behave "more like a browser" (cookie jar) - also, depends on pulp-instance supporting this at the middleware level
    • note that using cli-shell, you would only enter the pwd once per "session" (I think?)

2023

Dec 6

  • katello and bindings and multi-version issues
    • katello patches bindings post-generation
    • we're not going to rewrite pulp-glue in ruby
    • is there a way to do ruby-to-python, so katello can use pulp-glue instead of the bindings?
      • pybind?
    • katello could use the CLI as subprocesses
    • katello could use ansible/squeezer
  • pulp-glue and docs

Oct 25

Oct 11

  • look at translation mechanics in glue
  • do we want a pulp-glue talk at PulpCon?
    • could be dkliban talking about using it in pulp-replicator?
    • AI: mdellweg to ask dkliban if he'd like to do such a thing
    • what would the focus of such a talk be?
      • 30 min, DEV oriented
      • what is it?
      • why is it?
      • where is it already in use?
      • quick example of using it?
      • compare to doing same in bindings?
      • glue-support for some plugins live in diff packages (eg, ostree, maven, gem) - lib is extensible
  • lookit the cool updates to the docs-page!

Aug 16

  • import/export work is alive again
    • [ggainey] report back at next mtg
  • Question: do we delete old release branches.
    • older than 0.19?
      • 0.19 is first with new release process
    • 0.14 packaged for katello
      • because there's already a 0.14.1
    • 0.21.2 is latest-branch
    • conditional "yes"
      • keep 0.14 and 0.21
      • if we want to release on 0.14, will need the new release-process backported
  • installing CLI in same container as pulpcore Fun
    • pip is dumb
    • use the rpm dist
    • install into a virtenv
  • discussion w/ downstream around avoiding cross-version-conversations with client-bindings (not pulp-cli related)
    • pulp-glue exists for exactly this reason
    • except Ruby :(

Aug 2

  • release-workflow-improvements - DONE
    • 0.20.2 released w/ "fix" for pyyaml/cython problem
    • release-process needs a bit of tweaking - retry coming #soon
    • patchback now works on pulp-cli!
    • pulp-cli release-workflow now looks a lot more like everything else in /pulp/
    • will use experience here, to improve experience in pulpcore/plugins
  • click-8.1.4+ lint issues - DONE
  • python-3.12 is incoming (to release in Oct) - be prepared
  • A lot of versions of the CLI seem to be uninstallable for the PyYAML build issues.
    • 0.18.2 is the oldest working one. Should we yank all older from pypi?
    • prob should poke RPM Build Gang to RPM-ize something newer than 0.14.0
  • Are we ready / Do we need to declare supported branches for the CLI?
    • discussion ensues
    • maybe let's not borrow trouble - don't worry about unless/until a stakeholder tells us they need specific branches
  • Improve how a ca_cert is passed to pulp-glue
    • currently supported only via ca-bundle-support from request-module
    • dkliban to write up an issue
    • make sure it is available in the cli-profile setup
    • can we think of ways to make this a not-breaking change? Do we even care?
  • https://github.com/pulp/pulp-cli/pull/758

Jun 8

  • core and plugins have added features that haven't been exposed to cli
    • mini-teams should prob review and add issues (at least) to pulp-cli to get this work surfaced
  • pulp_gem plugin
    • cli-support should be moved to pulp/ org
  • pulp-cli needs to support all the branches in pulp-oci-image
    • what about pulp-maven?
    • no support currently
  • pulp-cli docs need another update review/work
    • esp docs "for us", as opposed to "how to use pulp-cli" for users
  • let's start thinking of higher-level/wizard/workflow commands that could be added to pulp-cli - get some RFEs open?
    • example: a single cmd to create remote/repo/sync/publish/distribute
  • squeezer and automation
    • can we finish the use-pulp-glue pieces?
    • how many plugins does squeezer currently support?

Apr 12

Mar 29

  • not much progress to report this week
  • api-quirks discussion
  • RE import/export CLI state
    • don't deprecate current/half-baked impl, just replace it
  • discussion RE pulp_python and import/export support
    • waiting on submitter

Mar 15

Mar 1

  • For discussion: should we be at 1.0 now?
    • let's not till pulp-glue is merged
    • let's not until import/export rework is merged
    • look at translation mechanics in glue
    • revisit at our next mtg
  • Prio-list?
  • Pulp-maven - separate repo or part of pulp-cli?
    • maven is part of container-image
    • put it under pulp_maven? - no
      • cli talks to multiple versions
      • should have its own release-cycle
    • separate repo?
      • "not part of official images" - takes more work if it's in pulp-cli
      • access/control of another group (eg pulp-deb)
      • demonstrate to other projects that you can have cli-plugins
      • [dkliban] will create plugin-repo for this, give all of us access
  • Replication commands
    • challenge: needs a pulpcore release
    • can teach CLI "this functionality requires 3.23.dev"
    • don't forget to add skip-clause to tests
  • domains cli-PR - will get a proper review #asap
    • cli-cfg-per-domain support discussion
    • conflict between what pulp-replication needs, and what domains-cli-PR is currently doing
    • dkliban/gerrod to get together and discuss later today

FEB 15

JAN 18

2022

Nov 23

Happened inbetween

  • There are A LOT of changes since 0.15, and a lot of things closed by not in 0.16 milestone - Release Soon pliz? [DONE]

Oct 26

Jul 6

Mar 16

  • label:triaged? or new issues get label:Triage-Needed?
    • Use the new label
    • Adjust the issue templates first
    • ggainey AI : PR 487
  • look for PR-template, point to our "how to contribute" docs

Mar 02

  • automerge discussion
    • disappointed in GH
    • will leave AM turned on (does no harm)
    • dismissal of reviews on change will be kept on
    • takeaway: be agressive about pushing the merge button
      • if it's green - Do It!
      • whoever pushes the button, isn't liable for bad reviews
      • still implies "do not Approve PR unless you're willing for it to be merged immediately "
  • What about a Release 0.14.0? Yes!
    • moved outstanding issues to 0.15.0

Feb, 16

  • Implement automerge on approved PRs?
    • Approve must be final
    • A change must dismiss any approval
    • request-for-change must be able to be reset/accepted by :the next reviewer", whoever that is
    • and the approving-reviewer is on the hook to do it!
      • Rules for auto-merge:
        • 1 approval
        • CI is green
        • no merge-conflicts
        • PR not in draft
    • if approved, and PR author removes Draft - automerge immediately?
    • Can we agree on a standard for "DO NOT APPROVE/MERGE THIS" in PR commit-message?
    • if applied in check-pr workflow, needs to reject merging AFTER CI runs
      • so it doesn't cancel CI like lint does
    • Timeline/to-do
      • x9c4 to experiment
      • switch next Weds 23-FEB?
  • Discussion RE container and differences in some commands from other plugins
    • Example: modify allows base-version, but NOT in container
    • should the command-name be same, even when "standard" arguments are not?
    • OR should command-name be plugin-specific even when most args are similar?
    • gerrod to sync up w/ ipanova to discuss and bring back to next mtg

2021

Oct, 27

  • different content is different (rpm) so it may need to go into different command groups
  • 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

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
  • 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

  • pulp-cli-deb
    • 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
  • 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
  • Translations

July 21

July 07

June 23

June 9, 2021

  • Packaging on Rhel/Centos 7 may not work with namespaced packages
    • Maybe we cannot use namespaced packages

May 26, 2021

May 12, 2021

April 28, 2021

  • Should we support plugin schema api changes?
    • Absolutely
    • 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
      • [[app_label:]type:]name
        • If the name has colons: ::name:with:colons
      • /pulp/api/repositories/<app_label>/<type>/pk
        • use repository-href
      • Are there forbidden characters for the name, we can use?
  • Migration support - https://github.com/pulp/pulp-cli/pull/142
    • Yay!
    • 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.
  • I18N
    • 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)
      • examples
        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
      • pros:
        • 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
      • cons:
        • 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)
      • examples
        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
      • pros:
        • may be more intuitive
        • consistent with pulp-admin (pulp 2) and hammer
      • cons:
        • 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
  • gettext
    • AI: x9c4 Yes please! at least get us into _() land

Jan 20, 2021

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

2020

Nov-12, 2020

Context: reviewing PR#27
Attendees: ggainey, x9c4
https://hackmd.io/hPligUXLRhSJBACNYLHNNw

  • 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

Other notes:

  • 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
    • Exporters
    • Tasks
    • Artifacts
    • Orphan cleanup
  • Stuff to do
    • Help text
    • Another plugin (rpm or container)
  • Recordings
    • ggainey to demo creating a cli command from scratch
    • Possible mypy demo?
  • Help text

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
  • Settings feature has been merged
  • Planning for next quarter?
    • Create a 0.1.0 release milestone in redmine?
    • for next quarter:
      • pulpcore
      • happy/main path through pulp_rpm
      • packaging
    • 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
  • Run CI every night?
  • Our first bug!
    • https://pulp.plan.io/issues/7666
    • 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, 'minutes'