Allow use of a configuration file `.beerc` comparable to `.drushrc`.

[MegaphoneJon]

Zulip discussion is here.

An initial focus would be on implementing global options.

Like .drushrc, bee should check for .beerc in several locations and concatenate the values, using a (documented) order of precedence.

Here is the order of precedence for `.drushrc:

• 1. Drupal site folder (e.g. sites/{default|example.com}/drushrc.php).
• 2. Drupal sites/all/drush folder.
• 3. In any location, as specified by the --config (-c) option.
• 4. User's .drush folder (i.e. ~/.drush/drushrc.php).
• 5. System wide configuration folder (e.g. /etc/drush/drushrc.php).
• 6. Drush installation folder.

example.drushrc is here for reference.

[yorkshire-pudding]

In #458 I added a default terminal width if tput cols fails to get the terminal width. This (i.e. $options['default-terminal-width']) would be a good candidate to include in an options file; it has less value as a standalone global option entered with each relevant command.

[izmeez]

After seeing the discussion during BD Live a few days ago I thought i'd give the .bee idea a try. Unfortunately, I was not ready to try it while in the discussion and now I can't seem to get it going. I must be missing a step or two. I have 2 options for bee on my dev setup: one uses the version 1.2.0 phar and the other uses bee in a git clone that is uptodate and if needed I can switch branches.

[yorkshire-pudding]

After seeing the discussion during BD Live a few days ago I thought i'd give the .bee idea a try. Unfortunately, I was not ready to try it while in the discussion and now I can't seem to get it going. I must be missing a step or two. I have 2 options for bee on my dev setup: one uses the version 1.2.0 phar and the other uses bee in a git clone that is uptodate and if needed I can switch branches.

@izmeez - this is not applicable to the topic. Please read the appropriate documentation and if necessary and once you are sure this is not a Windows issue, then raise a bug. I use this method all the time for my custom commands with no problem so I suspect it is your environment.

[izmeez]

@yorkshire-pudding I am having difficulty finding the documentation on using it.

[yorkshire-pudding]

@yorkshire-pudding I am having difficulty finding the documentation on using it.

@izmeez Here it is - https://github.com/backdrop-contrib/bee/wiki/Extending-Bee
The only reason I mentioned it was because I'm planning to put the bee_settings.php file in there too. At present, that folder is only useful for custom commands. I will say that I haven't tested that with a .phar file but as it works on the relative path from the Backdrop root, there is no reason why it wouldn't work.

[izmeez]

Thanks, I had found that page before but was expecting something more simple, like a json file with some desired options like --base-url=

[yorkshire-pudding]

@izmeez - the setting feature is not done yet (which should be apparent from the fact this issue has no PR and is still open). The discussion at Backdrop live was to check my thinking and see if anyone had any additional ideas.

[izmeez]

I hope this is not off topic, or that I can be redirected to the appropriate queue. During the recent BD Live discussions I was left with some questions about the naming convention this may introduce. Will there be a folder named .bee and inside that folder there may be various files including beerc.php or bee-rc.php for run control settings. There appeared to be some question as to what the file should be named. That file may contain global options.

[yorkshire-pudding]

@izmeez - this is a relevant question. My current proposal:

• Folders named .bee at either the same level as Backdrop root (i.e. ~/project/root/backdrop_root and ~/project/root/.bee) or in the home folder (i.e. ~/.bee) are currently scanned for custom bee commands. Bee does not add those folder, just looks for them.
• Bee will also look in those locations for a bee_settings.php file. I do not like the beerc pattern as while there may be some familiarity for drush users, it is meaningless otherwise, whereas Backdrop users will recognise the purpose of settings.
• The file(s) will be PHP files and contain an options array that will include global options and could also include command level options.
• The file(s) will support a limited version of site aliases defined by root at minimum, optionally base-url (if defined in settings.php may not be needed) and optionally site (for multisites).
• Options will not need the -- as used on the command line as this is simply used to identify the command argument as an option rather than an argument and is stripped out before it is passed to the command.
• They would be processed in order:

1. ~/.bee/bee_settings.php
2. ~/project/root/.bee/bee_settings.php
3. Command options

Within the settings file there will also be a hierarchy of global > site so specific options can be set for specific sites.

So any option in settings can be overridden in the command.

I hope that clarifies the plans. When this happens is another question, but it is high on my priority list.

[izmeez]

@yorkshire-pudding Thank you. I agree the name bee_settings.php is a better choice. Maybe similar to drush there can be an example.bee_settings.php file.

[izmeez]

Jumping the gun something like this:

<?php
/**
 * @file
 * Examples of statements for a Bee runtime config (bee_settings.php) file.
 *
 * Use this file to cut down on typing out lengthy and repetitive command line
 * options in the Bee commands you use and to avoid mistakes.
 *
 * Rename this file to bee_settings.php and optionally copy it to one of the
 * places listed below in order of precedence:
 *
 * 1.  In the .bee folder in the directory above the Backdrop web root.
 * 2.  User's .bee folder (i.e. ~/.bee/bee_settings.php).
 * 3.  System wide configuration folder (e.g. /etc/bee/bee_settings.php).
 * 4.  In any location, as specified by the --config (-c) option.
 * 5.  Bee installation folder.
 */

$options['default-terminal-width'] = '140';
$options['base-url'] = 'https://example.com';

I'm not sure what would be suitable equivalents for 3 and 4. Also 5 may need further clarification.

[yorkshire-pudding]

@izmeez - I'm not planning on doing 3 (I have nowhere to test this) or 5 (could be gitignore for people updating by git but would be overwritten if updating by deleting the folder and extracting the latest download in its place) but 4 could be a possibility.
The more places to put it, the more complicated it gets.