Hey!

To help keep things organized, we don't allow "Draft" pull requests. Could you please click the "ready for review" button or close this PR and open a new one when you are done?

Note that a pull request does not have to be "perfect" or "ready for merge" when you first open it. We just want it to be ready for a first review.

Cheers!

Carsonbot

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 5.4 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

Please use a descriptive title.

FYI. This will require an update to Flex-plugin as well as recipes expect this convention.

FYI. This will require an update to Flex-plugin as well as recipes expect this convention.

If we don't change the default, I don't think it will impact Flex (other parts of Flex already assume you use the standard symfony structure rather than a customized one)

FYI. This will require an update to Flex-plugin as well as recipes expect this convention.

If we don't change the default, I don't think it will impact Flex (other parts of Flex already assume you use the standard symfony structure rather than a customized one)

I think preferred approach would be to first implement a function that returns a config directory path without changing the default, with a possibility for a user to override it on his own responsibility. This will give some time to the flex and recipe developers to start relying on this function before decision is made if actually the directory name is gonna change.

@sstok probably means it somewhat requires an update of the recipes, e.g. https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/5.4/src/Kernel.php to make use of the config dir method.

I'm also 👎 as there are is not enough demand for such a change. People who really want to diverge from documentation and flex support etc, can just overwrite the relevant kernel methods themselves.

Hm.. I agree with @Tobion that it is not a great demad for this.

However, this patch is super small and Im not sure we have any other hard coded path like this.

This will (or SHOULD) obviously only be used by super advanced that have really good reasons by doing so. Just "I want to follow Unix standards" is not really a strong argument.

So, Yes, (almost) nobody should use this. But Im fine with this small patch anyways.

@ivanstan, may I ask you if you have a good reason for using /etc instead? What part of your work/application would be simpler if you could use /etc

@Nyholm To be honest its just my OCD. Other than the fact that all other directories are configurable.

Hehe. I’ve been there. But I guess that is something you need to fight though or override registerContainerConfiguration() and registerBundles() yourself.

I’m leaning towards closing this. I’ll wait an opinion from some other maintainer.

@Nyholm Yes, I have those methods overridden in most of my projects :)

im +1 if we update https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/5.4/src/Kernel.php :)

Done as part of #42991. Thank you.