Move all user-unrelated files under .beetbox dir

[AlexSkrypnyk]

Currently, it is very confusing for an end-users which files should be used in their custom projects.

Is it possible to move ansible and test dirs under .beetbox dir and bring config.yml into the root, so that the list of files an end-user can use is this:

• Vagrantfile
• config.yml *.gitignore
• README.md

Also, it is not clear why drupal8.make.yml is there and what it does. Especially, if beetbox targets non-Drupal platforms.

[Decipher]

I agree that the internals (ansible and test) should be put in a hidden folder, but I also wanted the config.yml file to be in the .beetbox directory (which I made happen and no one objected to given the appropriate amount of prompting) as I don't want my config to be a visible file in a project. It should be a set and forget file.

[AlexSkrypnyk]

@Decipher does this mean that your web files will be unde docroot dir or in the root of the repo?

[Decipher]

In docroot.

[Decipher]

Although it depends on the project. For a Profile based project the profile is the root (containing the Vagrantfile) but during the vagrant up it will build the codebase wherever (but for me, I still use docroot).

[AlexSkrypnyk]

how about we allow config.yml to be in the root OR inside of .beetbox? Moreover, we can even merge the 2, making the one in .beetbox to be a 'company-wide' config and outside of .beetbox to be a project-based.

[Decipher]

You can already do that by adjusting the following line in the Vagrantfile: https://github.com/drupalmel/beetbox/blob/master/Vagrantfile#L9

[AlexSkrypnyk]

I though the whole point was to not ever change Vagrantfile and use YAML for all configuration.

[Decipher]

Not necessarily. While I'd prefer to not have to have a special Vagrantfile as it adds confusion, hence me wanting to Package a default with the base box, there are certain things that you couldn't change in the config.yml, like the location of where the config.yml exists, because if it doesn't exist in the location where the Vagrantfile is looking you wouldn't be able to read the file to tell the Vagrantfile to look elsewhere.

[AlexSkrypnyk]

So I'm referring to the default Vagrantfile that is packaged with the box. Why can't we make it to look for config in multiple locations and merge settings from multiple files?

[Decipher]

Honestly, it's clearly a preference based thing. I personally don't like to see config of the my Stack while I developing, I just want it to work. Putting it in the .beetbox is a way have having it set and forget.

I'm happy to look at alternatives.

[thom8]

I like the idea because in some non-drupal projects there's a chance that there's already a config.yml defined in the root, this is basically namespacing it via the directory name.

The file could be called .beetbox but if it doesn't have the .yml file ending if might not get the correct file format in IDE's.

[Decipher]

Well, it could be called .beetbox.yml, but the reason I opted for a folder is that there is already a potential second config, and no doubt there will also be other stuff in the future, like tasks/roles.

[AlexSkrypnyk]

I love '.beetbox.yml' idea. If there are tasks in the future - the location can default to '.beetbox' dir for those files.

On Thursday, 14 January 2016, Stuart Clark notifications@github.com wrote:

Well, it could be called .beetbox.yml, but the reason I opted for a folder is that there is already a potential second config, and no doubt there will also be other stuff in the future, like tasks/roles.

— Reply to this email directly or view it on GitHub https://github.com/drupalmel/beetbox/issues/47#issuecomment-171495302.

[Decipher]

I'm not opposed to it, it's still hidden enough. @thom8 Can you elaborate on the purpose of the other settings file? Is there really a need for two config files?

[thom8]

if we're going to put tasks into a .beetbox directory we might as well just call it config.yml.

The other settings files are to extend the default config. project.config.yml could contain Acquia config so acquia projects could use a version which pulls in this config. local.config.yml is so you can keep overridden settings locally outside of git, you'd normally add this to gitignore. You might prefer more memory than the project default as an example.

[Decipher]

I think my current suggestion (for the sake of appeasing @alexdesignworks) is to have the following structure:

• .beetbox.yml
• .beetbox/tasks/*

Theoretically you could just go with: .beetbox.ENVIRONMENT.yml for any additional configs.

Personally, I'm happy to keep the .beetbox/config.yml file so that all .beetbox related stuff can be kept together and out of sight.

[AlexSkrypnyk]

I have patched Vagrantfile locally to use a config file named .beetbox.yml. It works great in terms that I have only a single place to have all my configuration and I do not need to have a .beetbox directory. I think .beetbox dir should be the dir where you would work on beetbox itself when you develop it (rather than ansible). That dir may also contain custom tasks, which may not be often required for a common project.

@Decipher I like what you have suggested with .beetbox.ENVIRONMENT.yml

@thom8 Can we remove the word config from any file names and use .beetbox instead? The reason is because a config word is too generic and it is not clear what this config is for. Right now, I have about 8 dotfiles in my repo and I can tell what they are just by looking at the name.

Can we please make a descision on this so that someone can start working on the PR. This is important because this is a an interface for the projects to use beetbox. If this interface changes later - it will be much harder to retrofit all these projects, so it would be nice if we can make changes ASAP.

[Decipher]

It shouldn't actually be all that hard to update if we do change this in the future, because at the moment your Vagrantfile is tracked in your own repository, so changes to said Vagrantfile only get made if you make them. Even when I move forward with the pre-packaged Vagrantfile, your own local Vagrantfile will be the master source for your own project, so if you have one, it will continue to work, and if you don't have one, it will fall back to the pre-packaged version.

Regardless, I agree a decision should be made. I'm happy to move forward with the suggestion of having a .beetbox.yml as the master config, but as I have not yet seen @thom8's mutli-config setup in place I feel it could be a partially un-informed decision.

[AlexSkrypnyk]

Just made this to refer to https://github.com/drupalmel/beetbox/wiki/Directory-structure

[AlexSkrypnyk]

@Decipher I'm struggling to understand why anyone would ever need to touch the Vagrantfile. It uses Ruby and web devs may simply not know it (I'm looking in the mirror). Isn't the whole point of all this to have a config only through YAML? Moifying Vagrantfile seems like an overhead to me - if ppl know how to do it they may also just use any other project.

[thom8]

@alexdesignworks once we have a stable release it would be highly discouraged to ever touch the Vagrantfile however while we are actively defining the default paths, you may need to manage a small patch to the Vagrantfile until these issues are resolved.

[AlexSkrypnyk]

@thom8, @Decipher Can we please make a decision on the original post and following discussions:

1. Move ansible dir into .beetbox dir.
2. Rename .beetbox\config.yml to .beetbox.yml
3. Support multiple locations for .beetbox.yml: /.beetbox.yml, /.beetbox/beetbox.yml
4. Decide to place future user tasks into .beetbox/tasks/*

[Decipher]

@alexdesignworks

1. Ansible dir is insignificant to end users, as they would never have it. It's only meant for the development of the Box itself. Once the quickstart guide is written, this will be clearer. But suffice to say, if you are cloning this repository then you are doing it wrong currently, but that's the fault of the documentation.
2. Until Thom can show us through his workflow, then this decision can't really be made.
3. I'd advise against this, because documentation and support is hard enough, without throwing extra confusion into the mix by saying that the config could be here, there or anywhere. If this is super important to you, you can do this by modifying your own Vagrantfile.
4. This is likely to be the case, but without having the ability to define custom tasks it would be unwise to make a decision.

[thom8]

1. I don't agree with moving the ansible dir.
2. Doesn't affect my workflow at all, my preference would be beetbox.yml in the root.
3. Supporting multiple locations would just make it harder switching between projects, we should just agree on the single location.
4. We don't have custom user tasks.

[Decipher]

So both @thom8 and me are pretty much in agreement. Let's go with this change for the moment:

Move .beetbox/config.yml to .beetbox.yml

We can revisit 4 when it's relevant.

[Decipher]

Ok, I don't agree then. The whole reason for having it as .beetbox/config.yml was so that it would be set and forget... forget as it's hidden. making it beetbox.yml doesn't make it hidden.

I don't see the need to see a file that shouldn't need to be dealt with once it's been setup. Much like a .travis.yml file, once it's set it doesn't need to be in your face. Especially for users who have the Vagrantfile in their actual docroot, which is a valid usecase.

[thom8]

We would also need to update local.config.yml to local.beetbox.yml.

At the end of the day we're aren't stopping anyone from customising the config file name or location but you need to manage a small patch of your Vagrantfile

[Decipher]

Which is why I said we can't make the decision until we've seen that workflow. Maybe we should hold off on this until we can all get together, it's not like this really has an real issues as it is, it isn't causing anything not to work.

[thom8]

I'm happy to do this - as it's not affecting me at all at the moment and it's really just semantics.

[AlexSkrypnyk]

Closing this one till beta release.