Hello, everyone. Welcome to the ✨ CLI in Core Initiative ✨ Meeting! 📅 This meeting:
➤ Usually happens weekly either at Wednesday 14:00 UTC or Wednesday 22:00 UTC.
➤ Will start synchronously for 30 minutes with an open agenda.
➤ Will then switch to 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. If you feel comfortable, mention what command, documentation or follow-up issue you are excited to work on!

mradcliffe Synchronous meeting attendees, mott (rymo), moshe (moshe weitzmann), mradcliffe, Thomas from Bluefly's notetaker
mradcliffe Matthew here (mradcliffe). I am very passionate about improving the install command, and I really want to get my previous work into a new merge request!
moshe hi all.
dww :wave: dww
bircher bircher I am looking forward to getting config import/export working

1️⃣ CLI in Core Initiative Meta.

1️⃣ 1️⃣ End of scheduled synchronous meetings.

mradcliffe We decided that we would not need to continue scheduled synchronous meetings, and will use Slack for remaining phases.@tekNorah can you cancel the meeting invites.We can still meet synchronously for any extra planning, collaboration, etc... of course :-)
tekNorah Done!

1️⃣ 1️⃣ Meta issue - https://www.drupal.org/node/3582246

mradcliffe Needs some cleanup on the roadmap that mradcliffe has offered to do.

2️⃣ Phase 2- We are now in the next phase. Congratulations to everyone over the years that has made this possible! :drupalparrot:

2️⃣ 0️⃣ Timeline

mradcliffe We do as much as possible for 12.0.0 beta, but not a lot of time, so understandable if we can't make 12.0.0 and 12.1.0 is next target.

2️⃣ 1️⃣ Follow-up issues:

mradcliffe -#3594184: CLI cannot discover commands in subdirectories that have a period in the name

2️⃣ 2️⃣ Commands:

mradcliffe Most Tier 1 commands have issues created for them. We talked about user:password and cache:clear, moving those to tier 2.
mradcliffe @mott noted that the system:status follow-up issue has not been created and needs to be created to complete it.
mradcliffe we talked about deprioritizing config commands, but those are still tier 1 for now. uli and updb are the most important commands.
mradcliffe Adding manual testing instructions (composer workflow and non-composer workflow) to https://www.drupal.org/community-initiatives/cli-in-core-initiative so they can be referenced in command issues, but general testing/steps to reproduce can be left up to implementers.
dww Agreed we need a follow-up to finish fleshing out the system:status command. It's mostly a stub at this point.
moshe I ported user:login. Needs tests. Help is appreciated.#3594332: Add a user:login command to generate a one-time login link (edited)
moshe Note that its an invokable command and uses #[Argument] and #[Option] attributes. Thats the modern way IMO
moshe I'm writing the tests now
moshe Its :white_check_mark:. Ready for review.
dww Reviewed. Opened a few MR threads, but it's very close to RTBC.

2️⃣ 3️⃣ API Documentation - https://www.drupal.org/docs/develop/drupal-apis/command-line-interface-c...

2️⃣ 4️⃣ User Documentation

mradcliffe What form should this take? The user guide is in the middle of GitLab migration, but some technical issues there. Any help for where to put this now?

2️⃣ 5️⃣ Other Phase 2 Related discussion here.

mradcliffe We talked about config module and maybe an idea of splitting config UI as a general core idea.
mradcliffe The exposed commands to the GUI issue is really cool.
mradcliffe I need to drop by the UX meetings or get[#3588144] this on the topic to figure out the best way. CC: @rkoller
rkoller i've added issue to the shortlist[#3592717]#comment-16615752  . but i am not sure if we could get to it already on the meeting on friday. i just saw darvanen already asked for demoing an issue he is working on (i havent looked at it yet) and we also have an issue from last week we also need to revisit another time (the revisiting can be moved to another week). in general the approach in those meetings is the people showing up to the meeting decide on which of the issues they want to work on.and in regard of the menu block for cli commands one question. at this point it is only about the cache rebuild command at this point?
dww I have serious concerns with exposing CLI commands in the GUI. I should reply (again) at the issue to explain my current thinking.
dww Okay, there:#3588144: Expose context sensitive help about any relevant CLI commands#comment-16615990

3️⃣ Rotterdam 2026

3️⃣ 0️⃣ Planning

mradcliffe Rotterdam is after 12.0.0-beta1, but we can get a lot of progress done.
dww I won't be able to attend Rotterdam. In fact, summer is busy AF for me, mostly offline (working at various music camps). So I probably won't be getting too much done for CLI over the next few months. TBD.

3️⃣ 1️⃣ moshe's session: https://events.drupal.org/rotterdam2026/session/joyful-tour-through-cli-...

mradcliffe Tentatively going over Command authorship, differences from Drush, the way forward from Drush, but hasn't started on it yet. He is open for collaboration.

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

4️⃣ 0️⃣ Install command discussion - rkoller in #cli-in-core

moshe Not sure. The install command on core is a toy. We touched it as little as possible in the initial MR. Further improvements will be in[#3594320]
mradcliffe Sorry, we're in the linked thread above since Ralf started right before I started pasting threads.
rkoller i might have one question in regard to dr install ... i just set up a new local instance for testing and after i mainly use drush si and drush cd most of the time i thought i try without requiring drush and see how things workout. but there is one detail i stumbled across. i've followedgit clone https://git.drupalcode.org/project/drupal.git drupal-dev
cd drupal-dev
ddev config --project-type=drupal12
ddev start
ddev add-on get amateescu/ddev-drupal-dev
ddev restart
ddev composer installbut when i runddev exec dr install standard --password=testI get:Drupal is already installed. If you want to reinstall, remove sites/default/files and sites/default/settings.php.even though the site is not installed yet. is that a known detail?
mradcliffe There are a couple of issues.
mradcliffe Install only works for SQLite at the moment -#3594320: Allow `dr install` to install when database is already configured
rkoller ahhh thanks! following both issues now
rkoller and on a related note looking at the overarching meta now, it looks like there is no issue yet for a username option. looking at the list of available options for the install command you are only able to change langcode, password, and site name but it is impossible to change the username on site install.
moshe yep - feature request
moshe it might be open already - the install command has been in core for a few years

4️⃣.1️⃣: Should dr try to discover commands in the Drush/Commands namespace and maybe generate a deprecation warning?

dww See dww in #cli-in-core for more...
dww Basically, although nod_ in #core-development has a list of some modules that already provide commands with AsCommand attributes, they generally use Drush/Commands namespace, so dr doesn't find them.
dww Should we do anything to try to ease this transition? Or are things in the Drush namespace doomed, likely to be trying to pull in drush-related code, and we're better off documenting how to "port" things to dr?
moshe better off documenting
bircher yes document porting
bircher I discovered the same and I think drush commands are using drush traits for example for autowiring
bircher but I experimented with extending the dr command for drush, so it is possible to offer both commands
bircher maybe drush could discover the dr commands?@moshe do you know if there is something that would prevent that from working?
moshe That would work. However, Drush is in maintenance at this point. Maybe thats a good idea if the Drush commands that have been replaced stop working for some reason.
moshe Oh, you mean discover the Contrib commands that work with dr . The goal presumably would be so that users dont have to switch between dr and drush. Meh - I would rather get folks pushed toward dr
bircher yes, from a contrib maintainer perspective I would like to maintain only one command. Because from a user perspective as long as most commands are available only in drush I can't move away from drush
bircher So if we can incentivise contrib maintainers to port their commands without the push back because their users would complain about their drush commands going away, I could see dr being a full replacement for drush when people move to Drupal 12 for example
moshe All that makes sense. I'm just not sure that keeping drush as a universal entrypoint furthers the goal of killing it.
bircher I understand that too
bircher I think we should find a way to transition as smooth as possible
bircher and I think if drush is very public about not supporting a specific future version of Drupal. (12 is maybe too early?) and we make it easy to transition to dr for contrib maintainers then a future drupal update will entail switching from vendor/bin/drush to vendor/bin/dr
bircher but of course we would have to contend with the possibilty that commands don't transition 1:1 and that some features are not on par
bircher so while there is now drush si and dr si one is clearly better than the other.. and so nobody wants to use dr right now (except enthusiasts in this channel of course)
moshe I'm not inclined to actively maintain Drush for 2 more years. Drupal is going to keep changing during the D12 lifetime and Drush is not going to keep up. And Drupal's changes sometimes cause Drush's features to break, despite Drupal's BC promise.
bircher yea I understand :smile: so maybe 12 is the answer
moshe Any work I do in this area will be on improving dr
bircher my argument is that as long as drush has more features/commands people are unlikely to start using dr and so we won't have a lot of help up-front from maintainers to convert their commands. But if the conversion is "backwards (ie drush) compatible" then it is a much easier sell
moshe You are saving the contrib maintainer the easiest part - extend a Console command into the Drush namespace
moshe They probably had to convert from a DrushCommands to a console command which is more work
bircher good point
bircher I already did the console conversion
bircher it was not that bad, the hooks annotation to event listeners is the hardest part really
bircher well, I am ok with enough documentation
bircher if you tell people in Rotterdam how "easy" they can switch to dr that is a huge deal too
bircher and if you announce Drupal 12 support of drush is unlikely/best effort, I think that is also a motivation to refactor and change habits
bircher I just think it is important to keep the momentum going for dr, otherwise there will be a fragmentation, sometimes you use dr sometimes you use drush.. etc

Participants:

mradcliffe, moshe, dww, bircher, tekNorah, rkoller, rymo

Comments

mradcliffe created an issue. See original summary.

smustgrave’s picture

smustgrave commented
Status: Needs review » Fixed

Credited the users mentioned and verified the threads captured.

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.