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

[Proposal] Use "config/" instead of "etc/" #56

Closed
javiereguiluz opened this Issue Apr 28, 2017 · 34 comments

Comments

Projects
None yet
@javiereguiluz
Member

javiereguiluz commented Apr 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Apr 28, 2017

Member

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

Member

fabpot commented Apr 28, 2017

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

@chalasr

This comment has been minimized.

Show comment
Hide comment
@chalasr

chalasr May 3, 2017

Member

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

Member

chalasr commented May 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Pierstoval

Pierstoval May 4, 2017

Contributor

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

Contributor

Pierstoval commented May 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@javiereguiluz

javiereguiluz May 4, 2017

Member

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

Member

javiereguiluz commented May 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Pierstoval

Pierstoval May 4, 2017

Contributor

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

Contributor

Pierstoval commented May 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@recchia

recchia May 12, 2017

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

recchia commented May 12, 2017

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

@imikay

This comment has been minimized.

Show comment
Hide comment
@imikay

imikay May 12, 2017

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.

imikay commented May 12, 2017

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.

@iltar

This comment has been minimized.

Show comment
Hide comment
@iltar

iltar May 12, 2017

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.

iltar commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@thunderer

thunderer May 12, 2017

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

thunderer commented May 12, 2017

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

@iltar

This comment has been minimized.

Show comment
Hide comment
@iltar

iltar May 12, 2017

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

iltar commented May 12, 2017

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

@chalasr

This comment has been minimized.

Show comment
Hide comment
@chalasr

chalasr May 12, 2017

Member

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

Member

chalasr commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Soullivaneuh

Soullivaneuh May 12, 2017

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 😉

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.

Soullivaneuh commented May 12, 2017

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 😉

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

This comment has been minimized.

Show comment
Hide comment
@greg0ire

greg0ire May 12, 2017

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)

greg0ire commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@javiereguiluz

javiereguiluz May 12, 2017

Member

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

Member

javiereguiluz commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@COil

COil May 12, 2017

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.

COil commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@haroldiedema

haroldiedema May 12, 2017

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.

haroldiedema commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@BPScott

BPScott May 12, 2017

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.

BPScott commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gerryvdm

gerryvdm May 12, 2017

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

gerryvdm commented May 12, 2017

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

@ecolinet

This comment has been minimized.

Show comment
Hide comment
@ecolinet

ecolinet May 12, 2017

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

ecolinet commented May 12, 2017

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

@mbadolato

This comment has been minimized.

Show comment
Hide comment
@mbadolato

mbadolato May 12, 2017

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

mbadolato commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@psampaz

psampaz May 12, 2017

+1 for config. Keep it simple.

psampaz commented May 12, 2017

+1 for config. Keep it simple.

@benstinton

This comment has been minimized.

Show comment
Hide comment
@benstinton

benstinton May 13, 2017

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

benstinton commented May 13, 2017

+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

This comment has been minimized.

Show comment
Hide comment
@rosier

rosier May 19, 2017

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

rosier commented May 19, 2017

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

@stof

This comment has been minimized.

Show comment
Hide comment
@stof

stof May 19, 2017

Member

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

Member

stof commented May 19, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@rosier

rosier May 19, 2017

@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

rosier commented May 19, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@Pierstoval

Pierstoval May 19, 2017

Contributor

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"

Contributor

Pierstoval commented May 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@teohhanhui

teohhanhui May 30, 2017

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

teohhanhui commented May 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@javiereguiluz

javiereguiluz Jul 3, 2017

Member

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

Member

javiereguiluz commented Jul 3, 2017

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

@iltar

This comment has been minimized.

Show comment
Hide comment
@iltar

iltar Jul 3, 2017

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

iltar commented Jul 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Jul 3, 2017

Member

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

Member

fabpot commented Jul 3, 2017

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

@xabbuh

This comment has been minimized.

Show comment
Hide comment
@xabbuh

xabbuh Jul 3, 2017

Member

👍 for doing so

Member

xabbuh commented Jul 3, 2017

👍 for doing so

@fabpot fabpot closed this in #122 Jul 3, 2017

fabpot added a commit that referenced this issue Jul 3, 2017

feature #122 Move etc/ to config/ and web/ to public/ (fabpot)
This PR was merged into the 1.0-dev branch.

Discussion
----------

Move etc/ to config/ and web/ to public/

fixed #56

Commits
-------

6bbb7e5 moved etc/ to config/ and web/ to public/
@VeeeneX

This comment has been minimized.

Show comment
Hide comment
@VeeeneX

VeeeneX Jul 7, 2017

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

VeeeneX commented Jul 7, 2017

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

@lukasz-zaroda

This comment has been minimized.

Show comment
Hide comment
@lukasz-zaroda

lukasz-zaroda Sep 3, 2017

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.

lukasz-zaroda commented Sep 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@javiereguiluz

javiereguiluz Sep 3, 2017

Member

@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/).

Member

javiereguiluz commented Sep 3, 2017

@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/).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment