amco / biran Goto Github PK
View Code? Open in Web Editor NEWAmcos bootstrap rails configuration gem
License: MIT License
Amcos bootstrap rails configuration gem
License: MIT License
Would be nice to have some generators for some basic files that we can supply to help a user get started.
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.
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
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 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.
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
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.
rake aborted!
NoMethodError: undefined method `root_path' for #<Biran::Config:0x007fb9144bc6a0>
/Users/brian/repos/biran/lib/biran/config_defaults.rb:54:in `secrets_file'
/Users/brian/repos/biran/lib/biran/configurinator.rb:57:in `build_app_config'
/Users/brian/repos/biran/lib/biran/configurinator.rb:29:in `initialize'
/Users/brian/repos/biran/lib/tasks/biran_tasks.rake:2:in `new'
/Users/brian/repos/biran/lib/tasks/biran_tasks.rake:2:in `block in <top (required)>'
/Users/brian/repos/biran/lib/tasks/biran_tasks.rake:1:in `<top (required)>'
/Users/brian/repos/biran/lib/biran/railtie.rb:8:in `block in <class:Railtie>'
/Users/brian/repos/cheddar2/Rakefile:6:in `<top (required)>'
/Users/brian/.rbenv/versions/2.4.1/bin/bundle:22:in `load'
/Users/brian/.rbenv/versions/2.4.1/bin/bundle:22:in `<main>'
(See full trace by running task with --trace)
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 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
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.
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.
When using biran in non rails app, we need to be able to pass an environment.
Looks like ruby 3.2 removed the .exists?
methods from file and dir. We need to switch to using just exist?
in the tests for those things. This is backwards compatible as the .exists?
methods have been depreciated for a long time.
https://msp-greg.github.io/ruby_3_2/file.NEWS.html#removed-methods
rake aborted!
NoMethodError: undefined method `deep_merge!' for nil:NilClass
/Users/brian/repos/biran/lib/biran/configurinator.rb:58:in `build_app_config'
/Users/brian/repos/biran/lib/biran/configurinator.rb:20:in `initialize'
/Users/brian/repos/biran/lib/tasks/biran_tasks.rake:2:in `new'
/Users/brian/repos/biran/lib/tasks/biran_tasks.rake:2:in `block in <top (required)>'
/Users/brian/repos/biran/lib/tasks/biran_tasks.rake:1:in `<top (required)>'
/Users/brian/repos/biran/lib/biran/railtie.rb:8:in `load'
/Users/brian/repos/biran/lib/biran/railtie.rb:8:in `block in <class:Railtie>'
/Users/brian/repos/bs/Rakefile:6:in `<top (required)>'
/Users/brian/.rbenv/versions/2.5.1/bin/bundle:23:in `load'
/Users/brian/.rbenv/versions/2.5.1/bin/bundle:23:in `<main>'
(See full trace by running task with --trace)
Provide more info and basic examples about configuration in README
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.
Rake tasks related to biran will break if no app_config.yml present.
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
They were used during initial development and can be removed now that methods are in place to work with them.
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.
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.
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.
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
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.
If generate_tasks list is not defined in app_config.yml
, I don't believe we are using the defaults from the configuration object.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.