On Tuesday, June 10, 2014 at 3:13 PM, Pier-Olivier Thibault wrote:
> I agree with Michael with 2 and 4. > > > > 2. Combine `boot.rb` and `environment.rb`. I'll be the first to admit I > > don't understand the Rails boot process as well as I wish, and there may be > > implications to this I don't understand. But in my informal testing, moving > > the contents of one file to another works just fine, and I personally > > having trouble seeing the distinction between the two. > > > Combining boot.rb and environment.rb (and possibly application.rb) would make > it easier for people to understand the booting process. boot.rb is actually > misleading since rails 4 (and 3?) since this is not booting anything. > application.rb could wrap all of this. > > 4. Move binstubs logic into the Rails gem executables. I haven't played > around with this yet and could be wrong, but I don't see why these files need > to be added to every app, when their logic could simply be included in the > rails/rake/bundle/spring gem executables. > Yes! The logic could very well live in the gem. > > I have actually made a github repository last week that highlighted what I > had in mind: https://github.com/pothibo/rails-flattened (bin/ folder is still > present since that path is hardcoded in rails' gem). I believe that with > Rails 5, a new folder structure should be promoted that would be lighter and > easier to understand for someone not used to Rails. ........... > > I guess we could tweak this repo and try to find a right structure, if people > are willing? How would you execute the rails binary without using `bundle exec` within an application? Wouldn't that defeat the purpose of binstubs? Rails isn’t installed on anything but our development machines outside of bundler. > > > On Monday, June 9, 2014 7:42:50 PM UTC-4, Ryan Bigg wrote: > > Replies inline. > > > > > > On 29 May 2014 14:35, Michael Kaiser-Nyman <micha...@gmail.com > > (javascript:)> wrote: > > > Hello! I teach quite a few people Rails through my class, Epicodus. One > > > thing I've noticed is that the sheer number of files and folders `rails > > > new` generates is pretty intimidating for newcomers to Rails. I'd like to > > > make a few suggestions to how to reduce that intimidation. > > > > > > 1. Don't create the `tmp` and `log` folders. These are automatically > > > created when `rails server` runs for the first time, so there's no reason > > > `rails new` needs to generate them. > > > > A quick explanation here that explains these folders is all that is > > required. The newbies can learn more about these as they come up. Tell them > > that it's safe to ignore these files for now. > > > > > > > > > 2. Combine `boot.rb` and `environment.rb`. I'll be the first to admit I > > > don't understand the Rails boot process as well as I wish, and there may > > > be implications to this I don't understand. But in my informal testing, > > > moving the contents of one file to another works just fine, and I > > > personally having trouble seeing the distinction between the two. > > > > Quick summary: bin/rails loads boot.rb, which tells Bundler to setup the > > load paths for the gems in the Gemfile (including Rails itself). The main > > purpose of this file is to set up the load paths for bin/rails, and allows > > Rails to use something other than Bundler if people are crazy enough. > > > > That file then loads rails/command which processes the args passed to > > "rails", which *can* lead it to loading config/environment.rb. Here's the > > stack trace: https://gist.github.com/anonymous/67ec70f672e6e9fba187. > > > > Combining boot.rb and environment.rb is not a good idea imo, because these > > two files serve their purposes well: one sets up the load paths, the other > > sets up the Rails application's environment. Slightly different, but > > important distinctions to make. > > > > > > > > > > > 3. Remove internationalization by default. I could be totally off-base, > > > but this feels like a feature that probably isn't used by a majority of > > > apps, and could easily be added by more experienced developers who need > > > it (and a Rails generator could be built to easily re-install it). > > > > I18n is an important feature to have and if you don't want to use it then > > you just don't. It's opt-in and newbies can get away without even referring > > to it during their first apps; just like what happens during the entire > > ~600 pages of Rails 4 in Action. > > > > > > > > > 4. Move binstubs logic into the Rails gem executables. I haven't played > > > around with this yet and could be wrong, but I don't see why these files > > > need to be added to every app, when their logic could simply be included > > > in the rails/rake/bundle/spring gem executables. > > > > I am not sure what you're suggesting here. Could you elaborate? > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscr...@googlegroups.com > (mailto:rubyonrails-core+unsubscr...@googlegroups.com). > To post to this group, send email to rubyonrails-core@googlegroups.com > (mailto:rubyonrails-core@googlegroups.com). > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
