[make:*] improve output messages for Symfony CLI users

[jrushlow]

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.

// Using the Symfony Binary
$> make:migration

...
Run `symfony console doctrine:migrations:migrate`
...

// Without
$> make:migration

...
Run `php bin/console doctrine:migrations:migrate`
...

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.

[OskarStark]

I am wondering if there is a better approach and find out if the user is using it actually?

[jrushlow]

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 symfony cli ultimately calls bin/console doctrine:migrations:migrate. The only way that I could think of is if the cli passed an additional flag like --from-symfony-cli to any make:* commands.. But I'm not sure that is something even worth doing...

Definitely open to idea's - It would be nice to be able conditionally show the correct message...

[OskarStark]

friendly ping @tucksaun

[tucksaun]

IIRC we didn't hide the original PHP binary path to prevent any compatibility issues.
So we can't make this transparent. But we might expose this to the Console component or to Maker Bundler via an environment variable?

[weaverryan]

But we might expose this to the Console component or to Maker Bundler via an environment variable?

That... WOULD be cool yes :). Is that a fairly simple thing?

[tucksaun]

The CLI part is easy to do: agreeing on the environment variable name(s) and content is the most complicated thing.
Then there's the PHP part where it depends how far you want to push things.

[jrushlow]

@tucksaun If you can expose an env like SYMFONY_CLI_VERSION: 1.0.0 I think that would do the trick. In MakerBundle we can check if that env exists then display the appropriate message. Using the version would also "future proof" things on our side - e.g. if we need to conditionally offer a feature based on the cli version..

[tucksaun]

but Symfony CLI binary can have another name that symfony, so we might want to expose both version and current binary name.

[jrushlow]

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. SYMFONY_CLI_NAME: some-binary-name && SYMFONY_CLI_VERSION: 1.0.0

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

[tucksaun]

see symfony-cli/symfony-cli#231

let me know if that would work for you this way.

[tucksaun]

CLI's PR has been merged so you can now rely on the presence of SYMFONY_CLI_BINARY_NAME as an envidronment variable

[OskarStark]

That will bring a much better DX 😃👍🏻 thanks

[jrushlow]

Thank you @tucksaun for making this possible in the binary!

[weaverryan]

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.

[jrushlow]

done - Using make:migration for the smoke test

[weaverryan]

Why not?

$binaryNameEnvVar = getenv(self::ENV_BIN_NAME);

if (false !== getenv(self::ENV_VERSION) && false !== $binaryNameEnvVar) {

[weaverryan]

Nice 👍

[maxhelias]

Could this be integrated directly into symfony/console ?

[jrushlow]

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?

[jrushlow]

Side note - do we have time to get it in for 6.2?

[stof]

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.

[tucksaun]

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?

[stof]

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)

[tucksaun]

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 ;)

[stof]

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 just console 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)