Rename config examples directory

[casperklein]

Description

To align with the documentation, this PR relocates the config directory.

See also discussion here.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change that does improve existing functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (README.md or the documentation under docs/)
• If necessary I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[georglauterbach]

Why the file mode changes (chmod -x) on the helper files? (I know this is a draft, just asking right away.)

[polarathene]

Since there was a request to continue discussion here..

@casperklein said:

PS: I find the new directory structure still weird. docker-data/dms suggest, that docker-data is a general docker directory, with DMS as one of many projects. In reality, I doubt, that someone will ever use this directory to place other docker-data in, beside DMS. Why would anyone want to mix-up his DMS stack with data not related to DMS.

While I understand the reasons for the renaming (easier handling of our docs), personally I find it strange to have the proposed directory structure in this repo.

As stated, it was an improvement to our docs with the normalization effort for consistency. If you grep the docs, you'll find other directories beyond dms used in docker-data.

This provides a root data/volume directory with sub-folder for each container, thus related data, but still isolated by associated container. I use this approach for storing data with multi-container projects as littering the volume dirs one level higher in a project structure isn't helpful.

---

@georglauterbach said:

I agree with @casperklein that the directory structure proposed in our docs is, at least IMHO, not likely to be found out there in the wild (i.e. a bit weird).

Like I replied above to casper, this is a structure I use and makes sense to me, and our docs to avoid any vagueness.

I would assume that our users are familiar enough with Docker that if they did not like the docker-data dir and had no need for the extra layer due to no additional containers or isolation needs, that they'd adjust it accordingly. If our docs are not clear enough on that freedom to do so, and you feel that should be clarified better, go for it :)

Personally, I don't see much benefit in changing the paths used, especially since they are more useful in the current state for maintaining the docs vs before when paths were inconsistent or overlapping (containers from different images using same/similar paths like config/, or unclear if referencing directory path from host or container) across various doc pages.

---

I'm open to it being handled better too. I just remember the state of the docs prior to normalization due to various contributors over time and this sort of thing slipping through where it was harder to correct.

I'm not going to defend the current choice more than that.

If maintainers disagree with the justification and think it's fine/better to simplify the path, that's all good too 👍

[polarathene]

Why the file mode changes (chmod -x) on the helper files?

See the commit message associated to them:

remove executable bit from scripts that are only sourced

[casperklein]

Minor change, I don't wanted to open a separat PR. Now it's streamlined with scripts/startup/* which has the same file mods.

[casperklein]

If you grep the docs, you'll find other directories beyond dms used in docker-data.

Okay, I wasn't aware of that. I took only the 4 paths from docker-compose.yml into consideration, when making my comment.

Going back to the previous approach (just using config and reverting the docs) is IMHO not an option. All the hard work on the docs from you would be useless.

But to avoid problems mentioned in #2436, the directory must be renamed. However, I am still not happy with the new long path.

What about renaming the config directory to config-samples? This way, you can also clone this repo and use setup.sh, but without headache like in #2436 + we avoid to have the long path in our repo.
People that want to use some or all of the example files, can easily copy them to their config directory.

[polarathene]

Redundant

However, I am still not happy with the new long path

That's only really an option with the config/ folder in the repo rather than the docs right? Isn't that folder more of an example?

It doesn't have to match the docs path, in fact it may be more clearer and less surprising if it's clearly example/config/ instead?

Is there a benefit to implicitly using that folder when a user clones the repo and uses setup.sh at the project root? I don't think the user expected that either. example/config/ should make it clear that it's an example only and not actually required to run. Some users do seem to get confused about that, similar to mailserver.env.

..I should really read the full message before replying 😅

---

What about renaming the config directory to config-samples?

Yes that works just as well as example/config/ 👍

[casperklein]

As long as there are no other subdirectorys, I would like to keep it flat.

What is better: config-samples or config-examples? I tend to the second one.

[polarathene]

What is better

config-examples seems good 👍

Or if it's more of a single example rather config-example?

[casperklein]

Or if it's more of a single example rather config-example?

There are various files in that directory. Plural is fine.

[georglauterbach]

LGTM 👍

Due to the file adjustments this PR has to wait until 10.5.0 is released.

[casperklein]

See milestone 😉

[github-actions]

Documentation preview for this PR is ready! 🎉

Built with commit: c183d40