Hello, everyone. Welcome to the ✨ CLI in Core Initiative ✨ Meeting! 📅 This meeting:
➤ Usually happens weekly either at Wednesday 14:00 UTC.
➤ Will use Slack threads to continue discussions.
➤ Please comment on the roll call thread throughout the day.

0️⃣ Roll Call! Who is here today? Introduce yourself including your name and drupal.org username.

mradcliffe Matthew here (mradcliffe). I'm running late today.
bircher :wave: currently on vacation

1️⃣ CLI in Core Initiative Meta discussions

1️⃣ 0️⃣ Meta Issue — #3582246: [meta] CLI in Core community initiative

mradcliffe I need to create an issue for the meeting last week still.

1️⃣ 1️⃣ Initiative documentation

mradcliffe Command issues need issue summaries updated to link to testing and porting documentation.
joachim Needs a docs page here: drupal.org/docs/develop/development-tools

2️⃣ Phase 2 Progress

2️⃣ 0️⃣ Folow-up [sic] issues

mradcliffe - #3587722: Consider what `dr` CLI command should do if it cannot bootstrap Core - #3587723: Consider a specific logger channel for CLI commands - #3594184: CLI cannot discover commands in subdirectories that have a period in the name - #3606744: Invokable commands dont show their usages in help - #3607060: ConsoleCompilerPass incompatible with symfony/console ≥ 8.1 - #3607072: Unable to use recipe commands on 11.4
mradcliffe Any suggestions on an issue tag to use to group these other than the meta issue?

2️⃣ 1️⃣ Command issues

mradcliffe - #3606744: Invokable commands dont show their usages in help

3️⃣ If you have anything else to talk about, please start a new thread below number 4️⃣ 5️⃣, etc...

Follow-up discussion from balsama

balsama Before I work on a MR, I'm curious if an option to bypass the isDrupalInstalled check in the install command would be considered? Or if that's been discussed already. (edited) 
rfay And, of course, to use a better technique to determine if installed. Drush uses content in database, current dr uses sites/default/files, etc. Pretty ugly
balsama That's actually what's getting in my way. So maybe just switching to checking to see if the DB is empty is what I should do.
mradcliffe I was thinking of fixing that directly in #3594342: Update install command to allow installing using any database driver , but there's also #3594320: Allow `dr install` to install when database is already configured
rfay Yes, it should also be able to force, even if db has content
balsama Thanks. #3594320 looks like a good fit for my MR
rfay IMO these two are the most important feature-bugs ever addressed on this (in the history of the built-in installer, what always kept me from using it at all)
mradcliffe I'm going to push some code up to the install with any db driver to handle existing connections if you wanted to compare @balsama
mradcliffe One thing that probably needs to be kept is that the command succeeds if drupal is already installed based on existing command usage to install & server for quickstart.
balsama Added an MR here: drupal.org/project/drupal/issues/3594320
mradcliffe @balsama were you intending to allow this to be used so that an existing database connection using mysql or pgsql would go through, or just an existing connection using sqlite?
balsama My intention was to use whatever connection is defined. But I didn't realize that conflicts with help text. I'll push a commit with a tweak to that now.
rfay The traditional way for this to work is using the settings.php/settings.ddev.php connection that are already established (if they are), otherwise adding them to settings.php. For DDEV it's important, because the correct db type is already configured
phenaproxima Does dr have the ability for event subscribers to add additional options to commands, the way Drush does?
moshe No. I'm not sure if core will go down that road. I kinda doubt symfony will.
phenaproxima Huh. I am able to get it to work using the ConsoleCommandEvent
moshe That doesnt work for adding options does it? Like, try to show the option in help and try to use it.
phenaproxima It does work although it doesn't show the added option in the help
moshe yeah in drush 14 i had to add a custom event for the help alter

Follow-up discussion from phenaproxima

phenaproxima Does dr have the ability for event subscribers to add additional options to commands, the way Drush does?
moshe No. I'm not sure if core will go down that road. I kinda doubt symfony will.
phenaproxima Huh. I am able to get it to work using the ConsoleCommandEvent
moshe That doesnt work for adding options does it? Like, try to show the option in help and try to use it.
phenaproxima It does work although it doesn't show the added option in the help
moshe yeah in drush 14 i had to add a custom event for the help alter

Follow-up discussion from joachim

joachim Does dr detect command classes that are in packages, rather than modules?
joachim This says ‘modules’ - drupal.org/docs/…/cli-api-overview But if that is the case, it would be useful for that page & code docs to say explicitly that  packages are not supported (since Drush does support them)
bircher if it doesn't, then it should support them.
joachim That would be nice 🙂
moshe You need a glue module that declares the services (via yml or serviceProvider) or you have to get your package to be named in $container->getParameter('container.namespaces'). See ConsoleCompilerPass::process().Are there examples of the comntainer discovering controllers, plugins etc. from /vendor? If not, this is unlikely to be added to dr.
bircher yea I have this idea of a new type of drupal extension that would take care of that. But I need to write it up properly.
joachim If that’s the design decision, then fair enough — it does make things simpler. needs docs though
moshe You might be able to hack in a service provider by adding an item to $GLOBALS['conf']['container_service_providers']. See discoverServiceProviders(). You'd need to get your code to load during runtime. One way is via your package's composer.json 
"autoload": {
        "files": [
            "src/runtime.php"
        ]
    }

(edited)
moshe yea I have this idea of a new type of drupal extension that would take care of that. But I need to write it up properly.I'm curious. Seems like a great spot for innovation.
bircher yes I never have time to write it up. I am drafting an issue and I plan to propose a BOF in Rotterdam
bircher the tldr is: a drupal extension that is more like a php library/package but can do some things a module can do, with some restrictions.
moshe Why restrictions? Seems like a module that lives in vendor would be a great solution
bircher restrictions because it would not have a "installed" or "uninstalled" state, it would just be there when it is there and not when it's not
bircher so oop hooks but no install uninstall schema etc
bircher autowired services and event subscribers and dr commands even before drupal is installed
moshe I;'m not sure its worth creating a new extension type just for having the feature of 'can't be inactive in the codebase'.
joachim Allowing modules in /vendor has previously been suggested as a long-term goal
moshe For sure. So long I've given up on core actually doing it. (edited)

Participants:

mradcliffe, bircher, joachim, rfay, balsama, phenaproxima, moshe

Comments

mradcliffe created an issue. See original summary.

smustgrave’s picture

smustgrave commented
Status: Needs review » Fixed

Credited the users mentioned.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.