-
-
Notifications
You must be signed in to change notification settings - Fork 406
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
[make:*] improve output messages for Symfony CLI users #1238
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering if there is a better approach and find out if the user is using it actually?
I was chewing on that too, but the Definitely open to idea's - It would be nice to be able conditionally show the correct message... |
friendly ping @tucksaun |
IIRC we didn't hide the original PHP binary path to prevent any compatibility issues. |
That... WOULD be cool yes :). Is that a fairly simple thing? |
The CLI part is easy to do: agreeing on the environment variable name(s) and content is the most complicated thing. |
@tucksaun If you can expose an env like |
but Symfony CLI binary can have another name that |
That would work too.. So long as whatever env name we use is consistent across releases so we can determine if the user is using a binary.. Or perhaps setting 2 env's. e.g. The actual names of the env vars don't really matter.. I think whatever works best on your side of the fence will work for us... |
…and `composer` wrappers Exposing those info via environment variables will allow better Symfony Maker experience, see symfony/maker-bundle#1238
…and `composer` wrappers Exposing that info via environment variables will allow a better Symfony Maker experience, see symfony/maker-bundle#1238
see symfony-cli/symfony-cli#231 let me know if that would work for you this way. |
…and `composer` wrappers Exposing that info via environment variables will allow a better Symfony Maker experience, see symfony/maker-bundle#1238
CLI's PR has been merged so you can now rely on the presence of |
That will bring a much better DX 😃👍🏻 thanks |
Thank you @tucksaun for making this possible in the binary! |
$this->assertStringContainsString('Success', $output); | ||
$this->assertStringContainsString('php bin/console make:migration', $output); | ||
}), | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's just add a test for the correct command to ONE of these makers (not all of them) just as a smoke test. It's too much added test code (and test running time) for such a minor detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done - Using make:migration
for the smoke test
src/Util/CliOutputHelper.php
Outdated
$envs = [ | ||
'version' => getenv(self::ENV_VERSION), | ||
'name' => getenv(self::ENV_BIN_NAME), | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not?
$binaryNameEnvVar = getenv(self::ENV_BIN_NAME);
if (false !== getenv(self::ENV_VERSION) && false !== $binaryNameEnvVar) {
putenv('SYMFONY_CLI_VERSION=0.0.0'); | ||
|
||
self::assertSame('symfony console', CliOutputHelper::getCommandPrefix()); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 👍
* | ||
* @internal | ||
*/ | ||
final class CliOutputHelper |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be integrated directly into symfony/console ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why not. We would need to add getters for the version & binary name (if not now, in the future) should the need arise where we need to conditionally change messaging in maker for some reason..
I can get a PR going in symfony/console
to get this in... Should it be done as helper like we have here or integrated directly into another part of an existing class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note - do we have time to get it in for 6.2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not put this directly in symfony/console. We currently have nothing exposing just this info in the component and php bin/console
is still specific to the Flex skeleton.
However, symfony/console
has an internal logic that would benefit from checking SYMFONY_CLI_BINARY_NAME
when replacing the placeholders in help texts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hacked something about this yesterday: https://github.com/symfony/symfony/compare/4.4...tucksaun:symfony:console/symfony-cli-full-command?expand=1
But I didn't submit it because I was afraid of any side effects for third party projects using symfony/console.
Do you want me to open the PR and discuss this there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is exactly the patch I had in mind. But ideally, we would have an env variable covering the whole symfony-cli command instead of hard-coding console
in symfony/console, as this would cause issues with symfony composer
for instance.
and I'm wondering of the effect when running symfony php
as the script itself is not wrapped there. so this requires more discussion before being readme (and it won't be for 4.4 as it reached EOM)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exactly the uses case I had in mind and lead me to not submit the patch yet :D
yeah I only targeted 4.4 by lazyness ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say that symfony-cli
should expose 2 env variables to solve that:
- an env variable exposing the wrapper command (to be decided whether we expose
symfony console
or justconsole
and expect the consumer to combine it with the existing env var for the binary name) - an env variable exposing whether the wrapper command is only wrapping PHP itself or also the PHP script (to decide whether it replaces the script name or only prefix it in symfony/console)
This PR was merged into the 1.0-dev branch. Discussion ---------- [git-released] v1.49.0 # Changelog ## [v1.49.0](https://github.com/symfony/maker-bundle/releases/tag/v1.49.0) *Jun 7th, 2023* ### Feature - [#1321](#1321) - Changing make:stimulus-controller to require StimulusBundle - *`@weaverryan`* - [#1309](#1309) - Apply `get_class_to_class_keyword` PHP-CS-Fixer rule - *`@seb`-jean* - [#1276](#1276) - [make:migration] Change message when required package for migration doesn't exist. - *`@bdaler`* - [#1261](#1261) - [make:registration-form] use UniqueEntity attribute instead of annotation - *`@jrushlow`* - [#1253](#1253) - [make:migration] Add link to new migration files - *`@nicolas`-grekas* - [#1251](#1251) - [make:*] use php-cs-fixer to style/lint all generated php templates - *`@jrushlow`* - [#1244](#1244) - [make:security:form-login] new maker to use built in FormLogin - *`@jrushlow`* - [#1242](#1242) - [make:*] use static return type instead of self for setters - *`@jrushlow`* - [#1239](#1239) - Improve error messages to show PHP & XML configurations are not supported - *`@ThomasLandauer`* - [#1238](#1238) - [make:*] improve output messages for Symfony CLI users - *`@jrushlow`* - [#1237](#1237) - [make:registration-form] Print registration form errors - *`@comxd`* ### Bug - [#1307](#1307) - [make:twig-component] handle upstream changes to how live components are rendered - *`@jrushlow`* - [#1270](#1270) - [make:authenticator] Core\Security or SecurityBundle\Security - Avoid deprecations in 6.2 - *`@nacorp`* - [#1265](#1265) - [make:crud] Make sensio/framework-extra-bundle an optional dependency - *`@acrobat`* - [#1264](#1264) - [make:controller] doctrine/annotations is not needed - *`@jrushlow`* - [#1262](#1262) - [make:reset-password] doctrine/annotations are not needed - *`@jrushlow`* _Generated by Git Released_ Commits ------- a7bb5c6 Updating date, adding 1 more PR cb06c33 [release] v1.49.0
To help with the situations described in symfony/symfony#46705 && #1235
If the user is using the Symfony binary, we check if
SYMFONY_CLI_BINARY_NAME
&&SYMFONY_CLI_VERSION
are set, then return the correct command prefix to in the output.E.g.
We are currently on checking that both of the envVars are set. In the future as we need to add/remove functionality based on the CLI version, we can check for explicit values of the env's if needed.