Why are we making a separate file for every single variable and permission?

This seems like total overkill and will end up creating thousands of files that will become unmaintainable.

Is D8 CMI doing it this way?

Putting them in one file instead seems better.

Comments

dagmar’s picture

D8 CMI doesn't have a rule for this. Some modules using a single file, others uses several files.

We 'could' save all the variables in a single file, same for permissions, but It needs some research because the whole system is designed to use a file per config.

There are Pros and Cons with the current system.

The main Pro is: developers will not be working in the same file if they are modifying two different permissions/variables.

The main Con is the amount of files that this system will generate.

Maybe we could provide two handlers and let users choose. I personally prefer the current system, but other developers could prefer have one file for all their variables and permissions.

dragonwize’s picture

The main Pro is: developers will not be working in the same file if they are modifying two different permissions/variables.

Can you explain this more? Why would developers ever be touching the files? The module itself is the only thing we support to actually write the files and the module only writes what is in the DB so where does the conflict come up?

dagmar’s picture

I was thinking in a team of developers working in a dev environment. If you have a single file that manages all the variables, a change in one variable, for example, one of pathauto, will override changes made for other developer working with the variable site-name.

Then developers have to coordinate their commits and reverts to avoid regressions.

lucascaro’s picture

Git usually handles edits on the same file pretty well, given that the file structure is clear enough, manual merges should be easy if needed.

If we want to rethink this (mabe for 7.x-2.1?) using a yaml file with var_name: 'serialized_value' with one variable per line would be a great way to manage variables, which would allow us to easily manage changes for different vars on the same file, and handle auto merges well.

Also we can have one less dependency (strongarm) which IMHO should be simple enough to replace and make the config files more easy to read and maintain.

codycraven’s picture

I concur, it is not the module's job to do version control. It is the module's job to support reverting UI changes (or exporting them) when they do not match the exports in the file system.

dagmar’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)