Can you somehow put somewhere in the readme the generated app directory structure?

Release 0.8.0 mainly focused on fixing some issues with Rake (specifically RSpec core Rake tasks being loaded in the production environment).

However, there are a few other things in addition to this that you might need to change in your application.

1. Remove RSpec core Rake tasks from Rakefile

   Old:

   require './app'
   require 'rspec/core/rake_task'
   
   task :default => [:spec]
   
   desc "Run the specs"
   RSpec::Core::RakeTask.new :spec

   New:

   require './app'

2. Change the CI script in .travis.yml from bundle exec rake to bundle exec rspec spec

   This is because the old CI script attempts to use the Rake task that we just removed in the step above.

   Old:

   language: ruby
   before_install: gem update --system
   script: bundle exec rake
   rvm: 2.5
   services:
     - postgresql
   addons:
   postgresql: '10.1'

   New:

   language: ruby
   before_install: gem update --system
   script: bundle exec rspec spec
   rvm: 2.5
   services:
     - postgresql
   addons:
   postgresql: '10.1'

3. Change your logging configuration in the production environment

   Currently, console output in the production environment is still stored in the generated log file. In most situations, this isn't desirable, as the console should always print to STDOUT. If you would still like it to be stored in the log file, you can skip this step.

   Additionally, if you would like to disable production logging entirely, you can still do this by using disable :log_file. This is often desirable on platforms such as Heroku which already handle logging.

   If you wish for console output to be sent to STDOUT, simply modify your config/logging.rb:

   Old:

   configure :production do
     enable :logging
     enable :log_file
   end

   New:

   configure :production do
     enable :logging
     # Output to log file except when running console
     set :log_file, !Eucalypt.console?
   end

4. Remove conditional IRB dependency

   As IRB is not bundled by default in Ruby versions >= 2.6, a quick fix had to be done to include the gem in the Gemfile only if using versions >= 2.6. This was done in the following way:

   Old:

   source 'https://rubygems.org'
   
   gem 'sinatra', '~> 2.0', '>= 2.0.4', require: 'sinatra/base'
   gem 'eucalypt', '0.7.2'
   gem 'rake', '~> 12.3'
   gem 'thin', '~> 1.7'
   
   # IRB is not bundled in Ruby >= 2.6
   if Gem::Version.new(RUBY_VERSION) >= Gem::Version.new('2.6')
     gem 'irb', require: false
   end

   This should be removed and changed to the following (observe line 3), since this check was unnecessary:

   New:

   source 'https://rubygems.org'
   
   gem 'irb', require: false
   gem 'sinatra', '~> 2.0', '>= 2.0.4', require: 'sinatra/base'
   gem 'eucalypt', '0.8.0'
   gem 'rake', '~> 12.3'
   gem 'thin', '~> 1.7'

Though I've tested what I believe to be the essentials of a generated Eucalypt application, I still haven't gotten around to writing any web-driven functionality tests.

The main functionalities that need to be tested with a web-driver are:

• That views, layouts and partials render correctly
• That the blog environment actually works:
  • Displays all blog articles
  • Displays a single blog article
  • Allows for searching of blog articles by tag
• That controller routers are mapping to the correct route
• That all controllers have access to ApplicationHelper
• That helpers are restricted only to the associated controller (unless it is ApplicationHelper)
• That all views have access to the Hanami tag/asset helpers

Since the freshly-generated applications don't really have any sort of interface, advanced web-drivers like Watir or Selenium don't really need to be used - the default Rack::Test::Methods should be enough (you'll find that this is already set up in spec/spec_helper.rb).

I suggest creating a new subdirectory spec/functionality and working on functionality tests in there.

For general information about Eucalypt and where to get started:

• README
• GitBook documentation

Removal of security commands

The sub-commands found in the security namespace generate a very highly opinionated authentication and authorization structure in the generated web applications.

Although this type of security structure worked well for me, it might be best to leave this up to the user to decide - especially because some of its implementation was quite hacky to start with.

I will therefore be entirely removing the security namespace and its sub-commands in future releases.