Flex: [Proposal] Use "config/" instead of "etc/"

[javiereguiluz]

This is a controversial topic that is often discussed in the Symfony Slack chat. More and more people are saying that etc/ is not the best choice because it's not that easy to understand.

At first I ignored them, but this idea is growing more and more in me. Names are great when you can understand them without explanation: "etc/" requires explanation and it complicates the first experience with the framework; whereas "config/" requires no explanation and it's exactly what everybody expects.

Other popular projects use "config/" (Laravel, Rails) and it's pretty common in PHP world too (according to these stats: http://paul-m-jones.com/archives/6564)

[fabpot]

Why not, I'm not opposed to the idea... and I will probably not fight much long on this one :)

[chalasr]

Not strongly against going back to config/ but I personally prefer etc/.
In addition to feeling unix (like var/) it covers stuff that I wouldn't put in config/, like encryption keys which are not about storage (do not fit in var/) and are read-only (they're piece of my setup, consumed by my configuration but are not settings themselves).

[Pierstoval]

Same as @chalasr, encryption keys or other things than config totally fit in etc/, whereas if you have config/, you would ask for a place to store such encryption keys and may end up with a new directory, specific to this...

[javiereguiluz]

Why don't you think that encryption keys fit into config/? Those keys configure the encryption used by the application. They are configuration to me (like any other credential or API token).

[Pierstoval]

It's the problem with config: not everyone have the same opinion about what to put inside.

With etc, it's unix-like, so as long as it doesn't fit anywhere else, it fits there :)

[recchia]

i prefer /etc but i'm ok with config i agreed with @chalasr

[imikay]

Please stop reassembly Linux terms in Symfony project, that's already too many etcs in Linux(/etc, /usr/local/etc), just use something straightforward and easy to understand by anyone, and config is a very commonly used name, we should just use it.

[linaori]

I don't have a hard argument that would favor either side to be honest. I know that /etc is really confusing for a lot of people and it took me time to find out what it actually meant. /config seems intuitive. However, using Linux, /etc kinda grew on me, but this is based on experience rather than being intuitive.

I agree with @chalasr, but isn't there another way you can do that? /config/keys for example. If the naming is intuitive or familiar, it beats being just familiar. My company is currently using /app/config/keys at the moment, which meets my expectations when I search for it or peek into the directory.

Personally, I feel that /config is what the community is used to because of /app/config. As it feels the most intuitive, that would have my vote, but either is fine for me.

[thunderer]

@fabpot published a poll on Twitter and /etc is losing strongly at the moment (29 : 71). I support /etc because it is a known convention, it is also consistent with /var, /bin and other such directories. I don't really understand what is to explain here - if anyone had any experience with Linux throughout their career (most of the industry definitely does), they will understand it immediately. If not, then a simple manual page like this should be more than enough. As for the "keys" example - personally, I put them in the separate directory like /keys or /etc/keys.

[linaori]

@thunderer don't forget that you can still customize what this directory is called

[chalasr]

Well, looking at a Symfony project for the first time it might not be obvious what should go into etc/. Let's keep it simple to adopt for newcomers and people that are not familiar with unix, config/ is the easy one (what I feel correct to put into is very subjective, not a blocker).

[soullivaneuh]

Both looks corrects to me. I would prefer config because this is the more used directory name on most web project, not only Symfony.

~Maybe make this configurable?~ => Already answered by @iltar :wink:

Personally, with a project based on Symfony but having Capistrano configuration and maybe others tools, I would like to configure all of them to have an unique config folder on my repository.

[greg0ire]

I'm torn between consistency with var, which would strongly suggest /etc, and the fact that /etc is not a great name... it's a bit like the Manager, Utils and Toolbox suffixes for a class (put things there if you don't want to think too hard about their location)

[javiereguiluz]

A small comment for people saying that "config/" is only for config and "etc/" is for anything. We already have a dir for "anything" and it's called "Resources/".

[COil]

I use /configuration/etc when I use exactly the same structure of /etc if not I use subfolders in configuration. So config is best as it is more generic I guess.

[haroldiedema]

The linux directory structure is a pretty common industry standard these days. As previously mentioned, people with a little bit of linux experience know what these directories are for.

If we are truely arguing whether etc is confusing for people, then the same can be said for the already existing directories bin and _especially_ var.

My OCD doesn't go well where half of the directory structure is using linux terms and the other half isn't. So yeah, please go with etc/ or find a better name/place for var as well. Perhaps move the logs and cache directories back to the root directory if we're going here.

[BPScott]

I'm well swayed by the the arguments that /config is more familiar and intuitive to PHP app developers. I do like that /etc provides an sensible dumping ground for things that don't fit elsewhere however as @javiereguiluz points out that the dumping ground already exists - /src/Resources (currently, though imo that should be updated to /resources) as per #40.

I'm leaning towards /config for obviousness and the flatter directory structure as /resources would provide a top-level dumping ground which is currently the main win for having an /etc directory for me.

I'm unconvinced by the arguments for providing a *nix-like directory - this is a PHP app, not a OS and while there are occasional similarities I don't think there is value in copying the *nix directory structure wholesale if it is opaque to people not already familiar with its conventions.

[gerryvdm]

@haroldiedema It is in no way a common industry standard for project layouts.

[ecolinet]

It's not an OS but it does have a Kernel... So you have to assume the *nix philosophy here

[mbadolato]

I saw that Paul Jones did a write-up discussing this and his mentioned some numbers he found when putting together his proposed pds/skeleton package. Perhaps it would be useful to reach out to him to discuss the research more in-depth (what was evaluated, how the evaluation was done, etc) to leverage the knowledge he gathered and what led to the decisions made for the skeleton?

Not that I'm proposing to go with the skeleton, just to garner more insight into other independent research that was done

[psampaz]

+1 for config. Keep it simple.

[benstinton]

+1 for config. config is much easier to understand for beginners and all levels of developers. Using etc to match *nix directory structure seems unnecessary, and a pursuit of style/form over accessibility/function.

[rosier]

How about renaming /etc/packages to /etc/config ?

[stof]

@rosier would be even worse IMO, as the whole etc folder is about config, not only etc/packages (other folders are about configuring different things that the container, but they are still config)

[rosier]

@stof I thought /etc was also for other stuff, but if the folder is just about configuration then I'm for renaming /etc to /config

[Pierstoval]

It's not _only_ about configuration.

It's for everything that is not code, not binary, not vendor, and not public resource.

config stores config. etc stores whatever doesn't fit in the other directories.

It's really different.

_"What doesn't fit anywhere fits in etc"_

[teohhanhui]

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Adapting it to the case of a Symfony project, etc should be for project configuration, etc.

Introducing a resources directory only creates more confusion, since we already have templates and translations (which are definitely "resources").

[javiereguiluz]

I've looked into some popular frameworks, and this is what I found:

| Framework | Config dir | Front controllers dir
| --------- | ---------- | ---------------------
| Symfony 3.x | app/config/ | web/
| Laravel | config/ | public/
| CakePHP 3.x | config/ | webroot/
| Zend Framework | config/ | public/
| Ruby On Rails | config/ | They don't use a traditional front-controller file (config.ru file at the project root dir) but they use public/ for public files
| Django | Project root dir (apps.py, settings.py, ...) | Project root dir (wsgi.py)
| Spring | config/ (but there are a lot of ways of configuring apps) | They don't use a traditional front-controller file (DispatcherServlet and web.xml) but public files can be stored in META-INF/resources/, resources/, static/ and public/

Considering this, not only could Flex (and Sf4) rename etc/ to config/, but also web/ to public/ (after all, Symfony is now a platform to develop web apps, APIs, microservices, etc. and not only web apps, so web/ looks weird for non-web apps).

[linaori]

@javiereguiluz while I don't have a strong opinion other than nostalgia: https://github.com/php-pds/skeleton

I know there is no real standard, but it does seem like the majority is using public.

[fabpot]

Ok, I will rename etc/ to config/ and web/ to public/ across the board if nobody objects.

[xabbuh]

:+1: for doing so

[VeeeneX]

Please note that you need to rename WEB_DIR to PUBLIC_DIR in composer.json

[lukasz-zaroda]

Just a thought, but nobody considered cfg as a compromise? It doesn't jump out as much as "config", is consistent with the style of names and is also self-explanatory. It would also go nicely along with "tpl" for templates.

[javiereguiluz]

@lukasz-zaroda cfg/ and tpl/ are not very self-explanatory in my opinion. Besides, there's not a strong reason to make these dir names short because you don't type them much in your Symfony apps (for example, to render a template you never add the templates/ dirname, so it doesn't matter that it's longer than tpl/).