Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the doctrine-dbal binary #5337

Merged
merged 1 commit into from
Mar 29, 2022
Merged

Conversation

derrabus
Copy link
Member

Q A
Type improvement
Fixed issues #5084 (comment)

Summary

This PR removes the doctrine-dbal binary deprecated with #5084.

@derrabus
Copy link
Member Author

The PHPCS error is unrelated to this PR. I can reproduce it on all maintained branches.

@derrabus derrabus added this to the 4.0.0 milestone Mar 29, 2022
@morozov
Copy link
Member

morozov commented Mar 29, 2022

This should be a side effect of the unlocked indirect dependencies. Must have been fixed in phpstan/phpdoc-parser 1.4.1.

@derrabus derrabus merged commit e026335 into doctrine:4.0.x Mar 29, 2022
@derrabus derrabus deleted the remove/dbal-binary branch March 29, 2022 20:44
$commands = [];
$connectionProvider = require $configFile;

ConsoleRunner::run($connectionProvider, $commands);
Copy link
Member

@morozov morozov Jun 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@derrabus so now that this file is removed, what's the role of the ConsoleRunner class? I see that it still exists but it's not used in the code. It doesn't seem to be used in DoctrineBundle either.

From the details you posted earlier in #5076 (comment)

[...] the DBAL and ORM commands are integrated into the applications console by DoctrineBundle.

It doesn't look like the runner is used there. It seems to have been used only by this file which no longer exists.

Should ConsoleRunner be deprecated and removed entirely?

UPD: I see it's used in the documentation. But it's not tested, so it's still mostly dead code.

In my understanding, it's a boilerplate code used to bootstrap a Symfony Console application. It may be useful only if the application that depends on the DBAL doesn't bootstrap one itself. Why should the DBAL maintain the code that should be possible to copy-paste from the documentation?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my understanding, it's a boilerplate code used to bootstrap a Symfony Console application.

Yes.

It may be useful only if the application that depends on the DBAL doesn't bootstrap one itself.

No. If your application bootstraps it's own console application, you can call ConsoleRunner::addCommands() to add the DBAL's commands to it. If it doesn't, ConsoleRunner::run() bootstraps the application for you and runs it.

Why should the DBAL maintain the code that should be possible to copy-paste from the documentation?

The idea is that ConsoleRunner::run() will remain a stable piece of boilerplate, even if we add/remove/rename command classes. Removing the class would complicate bootstrapping the console application unnecessarily.

But it's not tested, so it's still mostly dead code.

Let's add tests then.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. If your application bootstraps it's own console application, you can call ConsoleRunner::addCommands() to add the DBAL's commands to it.

There's currently just one command (the other is deprecated). ConsoleRunner::addCommands() accepts the same parameters as Application::addCommands(), i.e. requires a ConnectionProvider to be passed. What value does it provide this way?

The idea is that ConsoleRunner::run() will remain a stable piece of boilerplate [...]

That's what the documentation for the CLI framework is for. As soon as a user wants to make a change in their CLI application behavior (e.g. change the name, implement their own error handling), they will have to copy-paste our code. It's better to have them do that from the beginning.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current code violates the SRP since it acts both as a runner and a DI container for commands. I'd agree to keep the DI container part if there was a variety of commands and a complex dependency resolution but it's just one line of code that does nothing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current code violates the SRP

I really fail to see why this is a problem for bootstrap code, tbh.

I'm sorry, but assumed we've settled the discussion around the CLI tools already. The amount of time and energy I can invest in open source work these days is limited, so I'd rather not spend it on defending a piece of boostrap logic that I haven't even written myself.

Please remove ConsoleRunner if it really bugs you that much.

@morozov
Copy link
Member

morozov commented Jun 6, 2022

I really fail to see why this is a problem for bootstrap code, tbh.

The problem is that we may want to continue the support of a larger component just for the sake that a part of it may be useful (which practically isn't useful either).

I'm sorry that you had to waste your time. It is my fault that I didn't take a closer look at this code when we discussed it previously.

Please remove ConsoleRunner if it really bugs you that much.

Will do.

@morozov morozov mentioned this pull request Jun 9, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants