amco / biran Goto Github PK

The current setup assumes that an app using biran will have its public content in a directory named "public". That is a convention that may not be shared by all applications.

Right now, the db_config file override is all or nothing. So if we want to change one thing, we need to copy the entire config over instead of just changing the values we want to change

Provide more info and basic examples about configuration in README

Biran uses safe_load which now disables loading of aliases by default in the safe_load method.

We need to implement something like this or find another way in the process_config_file method

begin
  YAML.load(source, aliases: true, **options)
rescue ArgumentError
  YAML.load(source, **options)
end

https://stackoverflow.com/questions/71191685/visit-psych-nodes-alias-unknown-alias-default-psychbadalias

Environment variables for use in biran should be namespaced to avoid conflict with other, possibly pre-existing, environment variables.

Something like BIRAN_APP_ROOT would help differentiate and avoid conflicts.

As an example, we have cases where we want to generate multiple sidekiq config files to run multiple instance of sidekiq on the server to process the queue. Currently, we need to create a template file for each file we want to generate based on the name of the files to generate entry in config/app_config.yml. Those template files have the same structure just pull in different binding values to populate the output.
It would be nice if we could use a single template file that was able to dynamically figure out the block to use for data based on some value of the template. Easier to maintain long term.

If generate_tasks list is not defined in app_config.yml, I don't believe we are using the defaults from the configuration object.

When using biran in non rails app, we need to be able to pass an environment.

There is a need to create two files with the same name, yet in different output dirs. Currently, we pull the file name from the yaml block and assume the template name and the file name from that "label".
For instance, with the following block:

    files_to_generate:
      couchdb:
        extension: '.yml'

Biran will build a file at config/couchdb.yml from a template named config/_couchdb.yml.erb.
If we have a block that looks like:

    files_to_generate:
      couchdb:
        extension: '.yml'
        output_dir: '<%= File.join('bin', 'service', 'config') %>'

Biran would build a file at bin/service/config/couchdb.yml from a template named config/_couchdb.yml.erb
Both of those are great and working. But what if you need both in the same app. Only one would run based on those blocks also generating rake tasks and overriding the previously defined task.
Add to that the need to possibly have different erb templates for the two different files of the same name.

Try to catch some errors and spit out a better error message to give some relevance to where in the process it failed, perhaps which file or block, etc.

Getting errors in travis on the newer ruby versions as they use a newer rubygems which requires the newer bundler. So Bundler is not found on travis tests.

Would be nice to have some generators for some basic files that we can supply to help a user get started.

• config/app_config.yml
• config/_vhost.conf
• config/_database.yml
• config/local_config.yml.tmpl
• config/_settings.yml
• ???

All of these could be simple files that a user could then expand on. For instance, the vhost one could be a simple structured basic site to get a user running. We could include option to spit out an ssl enabled template as well.

Currently, the app_config object that is returned to the erb templates includes extra values that should only be used for setting up the application.

Any required/desired values that would be considered helpful should be placed into the output intentionally and not provided as a result of a deep merge.

When trying to run bundle exec rake config:generate without having the database.yml file configured to be generated, user gets an error about the missing template file

They were used during initial development and can be removed now that methods are in place to work with them.

The logic for loading/using the local file is duplicated and more complicated than it needs to be. Also, env variable doesn't match actual variable/method name used.

Rake tasks related to biran will break if no app_config.yml present.

On legacy apps that we are migrating, found this "issue" when putting vhost in the settings block and then trying to generate the settings.yml file in development using root_path instead of base_path:

Dump of @app_config shows the following when using root_path:

:app_root_dir=>#<Pathname:/Users/brian/repos/x4>, 
:app_shared_dir=>#<Pathname:/Users/brian/repos/x4>, 
:app_base_dir=>#<Pathname:/Users/brian/repos/x4>

And output in config/settings.yml looks like:

  vhost:
    public_dir: "/Users/brian/repos/x4/public"
    shared_dir: !ruby/object:Pathname
      path: "/Users/brian/repos/x4"
    log_dir: "/Users/brian/repos/x4/log"

When they should match the output when using base_path:

:app_root_dir=>"/Users/brian/repos/x4", 
:app_shared_dir=>"/Users/brian/repos/x4", 
:app_base_dir=>"/Users/brian/repos/x4",

and vhost looks like:

  vhost:
    public_dir: "/Users/brian/repos/x4/public"
    shared_dir: "/Users/brian/repos/x4"
    log_dir: "/Users/brian/repos/x4/log"

The difference being one looks to be a string and the other a path object.
Not sure if this is something worth fixing but would like to look into it

Getting deprecation notices when running on ruby 3.1.2

lib/biran/erb_config.rb:57: warning: Passing safe_level with the 2nd argument of ERB.new is deprecated. Do not use it, and specify other arguments as keyword arguments.
lib/biran/erb_config.rb:57: warning: Passing trim_mode with the 3rd argument of ERB.new is deprecated. Use keyword argument like ERB.new(str, trim_mode: ...) instead.

Biran is currently calling Erb.new using the legacy positional arguments. We need to change to using named based arguments which have been supported since ruby 2.6.
As of the new erb gem, the options have been giving warnings when used.

When running rake config:generate and we only want to run for vhost or anything besides database and the db_config.yml file does not exists, we get this error.

Currently, we have to define repetitive tasks to generate different files. Should be able to dynamically define this list and use meta programming to create tasks dynamically from list.

@brlanier @javierg , since this always need the same files to be present, what do you guys think about adding an install that copies the templates over, or .example of each so you don't have to remember to copy each one from some other app

On building the project as gem, we have this warning shown

WARNING:  open-ended dependency on railties (>= 0) is not recommended
  if railties is semantically versioned, use:
    add_runtime_dependency 'railties', '~> 0'
WARNING:  open-ended dependency on rails (>= 0, development) is not recommended
  if rails is semantically versioned, use:
    add_development_dependency 'rails', '~> 0'
WARNING:  open-ended dependency on bundler (>= 0, development) is not recommended
  if bundler is semantically versioned, use:
    add_development_dependency 'bundler', '~> 0'
WARNING:  open-ended dependency on rspec (>= 0, development) is not recommended
  if rspec is semantically versioned, use:
    add_development_dependency 'rspec', '~> 0'
WARNING:  open-ended dependency on tapout (>= 0, development) is not recommended
  if tapout is semantically versioned, use:
    add_development_dependency 'tapout', '~> 0'
WARNING:  open-ended dependency on rspec-ontap (>= 0, development) is not recommended
  if rspec-ontap is semantically versioned, use:
    add_development_dependency 'rspec-ontap', '~> 0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help

If you try to include some values in a secrets block in app_config.yml, it will not show up as values in a template. For example, if you want to avoid even using the config/secrets.yml file and try to put the values in the app_config.yml file, the values will not exist for use in a template.

When running config generate or any config tasks in travis, the task is not using the supplied RAILS_ENV=development on the command line.

This can be seen by including changes in the development block in the config/app_config.yml file and then checking the output in a generated file. You will not see the development values, only the default and possibly any values from test.