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

Clarification needed on upgrade instructions #9230

Closed
feamsr00 opened this issue Feb 9, 2018 · 10 comments
Closed

Clarification needed on upgrade instructions #9230

feamsr00 opened this issue Feb 9, 2018 · 10 comments

Comments

@feamsr00
Copy link

feamsr00 commented Feb 9, 2018

Hello,

If the environment being upgraded (from <3) is using parameters.ini (or .xml) the composer update process will crash hard during post-update-cmd event's Incenteev\ParameterHandler\ScriptHandler::buildParameters.

Some guidance is required indicating what to do about this. Whether its to disable post-update-cmd event or to remove Incenteev's ParameterHandler, or etc

@xabbuh
Copy link
Member

xabbuh commented Feb 9, 2018

What kind of crash did you experience? Did you update to Symfony 3 or 4?

@javiereguiluz
Copy link
Member

I'm closing this because of the lack of feedback. It's strange that the error happens when using INI params with Symfony 2 because, even if INI config files are discouraged since a long ago, the latest Symfony version includes the IniFileLoader class that parses INI files.

If you have more details about how to reproduce the bug, please reopen this issue. Thanks!

@feamsr00
Copy link
Author

Hi!
Indeed I do have additional details. It seems this happens because of the ScriptHandler isn't using Symfony's inifileloader, it is using something internal. To be clear this is happening on the "post-install-cmd" step.

If I don't have an yml.dist or a ini.dist, which is where we started and was confusing enough:

> Incenteev\ParameterHandler\ScriptHandler::buildParameters
Script Incenteev\ParameterHandler\ScriptHandler::buildParameters handling the post-install-cmd event terminated with an exception


  [InvalidArgumentException]
  The dist file "approot_main/config/parameters.ini.dist" does not exist. Check your dist-file config or create it.

This is if I create a blank parameters.ini.dist

> Incenteev\ParameterHandler\ScriptHandler::buildParameters
Script Incenteev\ParameterHandler\ScriptHandler::buildParameters handling the post-update-cmd event terminated with an exception

Updating the "approot_main/config/parameters.ini" file

  [InvalidArgumentException]
  The top-level key parameters is missing.

If I copy the contents of my ini file to ini.dist:

> Incenteev\ParameterHandler\ScriptHandler::buildParameters
Updating the "approot_main/config/parameters.ini" file
Script Incenteev\ParameterHandler\ScriptHandler::buildParameters handling the post-install-cmd event terminated with an exception


  [Symfony\Component\Yaml\Exception\ParseException]
  Unable to parse at line 1 (near "; These parameters can be imported into other config files").

Now, I don't know if this became an issue before 2.8 (we were only going from 2.3 to 2.8 for now) because we only just started using composer to manage Symfony and its deps (previously we just "vendor'd" the Symfony standard distribution)

For the record, we like using .ini files because of our build management tool which reads\writes to them between deployments\environments (and it's much simpler using simple ini across teams and tools then inflecting the oddities of yaml on everything).

@feamsr00
Copy link
Author

@javiereguiluz Is that response fine here? Will you reopen this or should I create a new issue?

@javiereguiluz
Copy link
Member

There are several issues here:

  1. The .dist file is mandatory to make this work. In the Incenteev Param HAndler doc you can read about it: https://github.com/Incenteev/ParameterHandler
  2. The second error says that [parameters] key is missing. Look at the default (legacy) parameters.ini file from Symfony: https://github.com/symfony/symfony-standard/blob/2.0/app/config/parameters.ini
  3. The last error Unable to parse at line 1 can only mean that the format of the INI file doesn't follow the required structure. Look again to the INI file from Symfony to fix it: https://github.com/symfony/symfony-standard/blob/2.0/app/config/parameters.ini

If you still can't make it work, use any of the support services provided to the Symfony community: https://symfony.com/support Thanks!

@feamsr00
Copy link
Author

Hi @javiereguiluz thank you for those tips!

For the record, I'd just drop a note in the documentation somewhere that says pretty much what you put there. It would lead to a softer "landing" for folks coming from older versions.

...is what I what I was about to say, but then I recalled. Incenteev is actually the problem here. It has no support for ini files! (See Incenteev/ParameterHandler#114)

I'd think the "Symfony way" wouldn't include randomly abandoning config formats. And I'm not sure what Incenteev's issue is considering Symfony has excellent libs for handling config formats. So, documentation-wise, ... i'm not sure. Thoughts?

@feamsr00
Copy link
Author

For the record, I'm not sure what role that code is supposed to fill, considering symfony config can already merge & overide configuration files and settings. What am I missing?

http://symfony.com/doc/current/components/config/definition.html#processing-configuration-values

@xabbuh
Copy link
Member

xabbuh commented Apr 13, 2018

That's the same code that is used by the full stack framework under the hood. This section just explains how one would use the Config component standalone.

@feamsr00
Copy link
Author

feamsr00 commented Apr 14, 2018

Hi @xabbuh . That makes sense. Considering how useful, complete, and flexible it is, why isn't that used for this parameter handling... "doodad"? What is it doing that Symfony isn't/can't/won't? Especially considering that it would not appear to be feature complete?

@xabbuh
Copy link
Member

xabbuh commented Apr 14, 2018

Parameters are just values. They don't have any semantic in itself. Their meaning is derived from where you use them. Not sure what you would want to change about that. Maybe the discussion that happened in symfony/symfony#26713 is of interest for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants