Re: [Rails-core] Simplifying `rails new`
Is there any compelling argument for why the current structure is broken?
Is this just a aesthetic and/or stylistic proposal?
Most of the larger apps I work on have 10-15 files in initializers. Squashing
them into on 1 file not a good option to me.
Inside the app/ folder of larger Rails apps you might have 10 different folders
or more: assets, contexts, controllers, extenders, helpers, jobs, mailers,
models, observers, presenters, serializers, services, uploaders, views. Having
an app/ folder is a good thing IMHO, because I don't want all these sprawled
throughout my root directory.
The only thing that doesn't make sense to me about the default Rails structure
is the lib directory, which I think belongs inside of app/ since it often
contains app code.
On Jun 11, 2014, at 6:42 PM, Matt Jones al2o...@gmail.com wrote:
On Jun 11, 2014, at 3:13 PM, Pier-Olivier Thibault poth...@gmail.com wrote:
On Wednesday, June 11, 2014 3:57:59 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 12:32 PM, Joe Fiorini j...@joefiorini.com wrote:
I actually played with simplifying the structure some time ago, although
for a completely different use case. I didn't end up going further than
posting this PoC on Github, but it does actually boot up a Rails app.
My changes:
I moved all application/environment config into a file called
{APP_NAME}.rb. Inside this file I have a module/class definition for the
application the same as any standard Rails app (looks like I accidentally
made it a class rather than Application class inside APP_NAME module,
oops), but I also added a Ruby DSL for specifying environment configs. IME,
the files under config/environments don't normally get a ton of options, so
having them all in one place would actually be easier.
Would this mean smashing all the files in config/initializers into one file?
That would make generators that wanted to create a default initializer (for
instance, the Devise InstallGenerator) much more complicated since they'd
need to insert code into the singular environment.rb file rather than just
drop a whole file into config/initializers.
I believe it would be the opposite, people, instead of using the
config/initializers/*.rb, they would use mechanics that Rails provides by
default - The initializer method that any railtie class have. Here's an
example of an application.rb file that would include such
initializer:https://gist.github.com/pothibo/a32f686aed0f03729157
In your example, the generator would have to *insert* an additional
`initializer 'whatever' do` block into the existing generator. That's already
going to make things more complicated; finding the appropriate place is not
trivial, especially if the generator needs to play nice with namespaced
applications, such as:
module MyTopLevel
module MyProject
class Application Rails::Application
initializer 'configure devise' do |app|
app.config.devise.somethin = 'blabla'
end
end
end
end
A simplistic strategy (insert before the 2nd end from the end of the file)
will fall down here.
More importantly, the *size* of what's added is significant. The Devise
generator alone drops 260+ lines (mostly comments) to help users configure
things.
The application.rb file seems like it could get quite long, and then somebody
will propose to split it up into, say, a directory of smaller files... :)
--Matt Jones
I also haven't seen much discussion of the set up the paths but don't load
the whole env reasoning for boot.rb being separate from environment.rb
(mentioned down-thread by Ryan Bigg). Is this still something useful? If it
isn't, how will (for instance) Rake tasks that don't depend on :environment
be switched over?
--Matt JOnes
I also removed the app folder and put directories that were in that
folder in the root. This change was specific to the particular use case I
was designing this for, API-only apps that don't have as much need for the
app distinction.
Once I started thinking about a smaller Rails structure, the idea of the
config folder seemed unnecessary. Anytime I need access to my app's
environment I require application.rb, so to me the distinction between
that and environment.rb doesn't serve much purpose. Given that, why can't
boot.rb be in the root and all the environment config be consumed into
application.rb with a DSL for creating environments like above?
On Tuesday, June 10, 2014 6:50:48 PM UTC-4, Pier-Olivier Thibault wrote:
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.
I think this is somewhat open to discussion. What is the difference between
'bundle exec rails server' and './bin/rails server' besides the longer
command, of course?
I
Re: [Rails-core] Simplifying `rails new`
On Jun 11, 2014, at 9:34 PM, Pier-Olivier Thibault poth...@gmail.com wrote:
You are right. However, the initializers is not really what's discussed here.
it's the whole directory structure. Anyway, I think config/ folder still has
its place( and the initializers for all I care). I think the issue is that
over the years, the project structure for Rails has grown to have a lot of
different folder and the meaning of all those folders is not that obvious.
Initializers were never a part of the discussion anyway until you mentionned
it.
The post I originally replied to (from Joe Fiorini) mentioned the config folder
potentially being unnecessary. That would tend to involve initializers. :)
—Matt Jones
On Wednesday, June 11, 2014 6:42:52 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 3:13 PM, Pier-Olivier Thibault pot...@gmail.com wrote:
On Wednesday, June 11, 2014 3:57:59 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 12:32 PM, Joe Fiorini j...@joefiorini.com wrote:
I actually played with simplifying the structure some time ago, although
for a completely different use case. I didn't end up going further than
posting this PoC on Github, but it does actually boot up a Rails app.
My changes:
I moved all application/environment config into a file called
{APP_NAME}.rb. Inside this file I have a module/class definition for the
application the same as any standard Rails app (looks like I accidentally
made it a class rather than Application class inside APP_NAME module,
oops), but I also added a Ruby DSL for specifying environment configs. IME,
the files under config/environments don't normally get a ton of options, so
having them all in one place would actually be easier.
Would this mean smashing all the files in config/initializers into one file?
That would make generators that wanted to create a default initializer (for
instance, the Devise InstallGenerator) much more complicated since they’d
need to insert code into the singular environment.rb file rather than just
drop a whole file into config/initializers.
I believe it would be the opposite, people, instead of using the
config/initializers/*.rb, they would use mechanics that Rails provides by
default - The initializer method that any railtie class have. Here's an
example of an application.rb file that would include such
initializer:https://gist.github.com/pothibo/a32f686aed0f03729157
In your example, the generator would have to *insert* an additional
`initializer ‘whatever’ do` block into the existing generator. That’s already
going to make things more complicated; finding the appropriate place is not
trivial, especially if the generator needs to play nice with namespaced
applications, such as:
module MyTopLevel
module MyProject
class Application Rails::Application
initializer 'configure devise' do |app|
app.config.devise.somethin = 'blabla'
end
end
end
end
A simplistic strategy (“insert before the 2nd end from the end of the file”)
will fall down here.
More importantly, the *size* of what’s added is significant. The Devise
generator alone drops 260+ lines (mostly comments) to help users configure
things.
The application.rb file seems like it could get quite long, and then somebody
will propose to split it up into, say, a directory of smaller files… :)
—Matt Jones
I also haven’t seen much discussion of the “set up the paths but don’t load
the whole env” reasoning for boot.rb being separate from environment.rb
(mentioned down-thread by Ryan Bigg). Is this still something useful? If it
isn’t, how will (for instance) Rake tasks that don’t depend on :environment
be switched over?
—Matt JOnes
I also removed the app folder and put directories that were in that
folder in the root. This change was specific to the particular use case I
was designing this for, API-only apps that don't have as much need for the
app distinction.
Once I started thinking about a smaller Rails structure, the idea of the
config folder seemed unnecessary. Anytime I need access to my app's
environment I require application.rb, so to me the distinction between
that and environment.rb doesn't serve much purpose. Given that, why can't
boot.rb be in the root and all the environment config be consumed into
application.rb with a DSL for creating environments like above?
On Tuesday, June 10, 2014 6:50:48 PM UTC-4, Pier-Olivier Thibault wrote:
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.
I think this is somewhat open to discussion. What is the difference between
'bundle exec rails server' and './bin/rails server' besides the longer
command, of course?
I would personally pay the cost of longer commands to see
Re: [Rails-core] Simplifying `rails new`
I actually played with simplifying the structure some time ago, although
for a completely different use case. I didn't end up going further than
posting this PoC on Github, but it does actually boot up a Rails app.
My changes:
I moved all application/environment config into a file called
{APP_NAME}.rb. Inside this file I have a module/class definition for the
application the same as any standard Rails app (looks like I accidentally
made it a class rather than Application class inside APP_NAME module,
oops), but I also added a Ruby DSL for specifying environment configs. IME,
the files under config/environments don't normally get a ton of options, so
having them all in one place would actually be easier.
I also removed the app folder and put directories that were in that
folder in the root. This change was specific to the particular use case I
was designing this for, API-only apps that don't have as much need for the
app distinction.
Once I started thinking about a smaller Rails structure, the idea of the
config folder seemed unnecessary. Anytime I need access to my app's
environment I require application.rb, so to me the distinction between
that and environment.rb doesn't serve much purpose. Given that, why can't
boot.rb be in the root and all the environment config be consumed into
application.rb with a DSL for creating environments like above?
On Tuesday, June 10, 2014 6:50:48 PM UTC-4, Pier-Olivier Thibault wrote:
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.
I think this is somewhat open to discussion. What is the difference
between 'bundle exec rails server' and './bin/rails server' besides the
longer command, of course?
I would personally pay the cost of longer commands to see lighter project
file structure as I'm going to spend much more time in the project than I
will executing commands. It's important to note that rake tasks are going
to stay as is.
--
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.
Re: [Rails-core] Simplifying `rails new`
On Jun 11, 2014, at 12:32 PM, Joe Fiorini j...@joefiorini.com wrote:
I actually played with simplifying the structure some time ago, although for
a completely different use case. I didn't end up going further than posting
this PoC on Github, but it does actually boot up a Rails app.
My changes:
I moved all application/environment config into a file called
{APP_NAME}.rb. Inside this file I have a module/class definition for the
application the same as any standard Rails app (looks like I accidentally
made it a class rather than Application class inside APP_NAME module, oops),
but I also added a Ruby DSL for specifying environment configs. IME, the
files under config/environments don't normally get a ton of options, so
having them all in one place would actually be easier.
Would this mean smashing all the files in config/initializers into one file?
That would make generators that wanted to create a default initializer (for
instance, the Devise InstallGenerator) much more complicated since they’d need
to insert code into the singular environment.rb file rather than just drop a
whole file into config/initializers.
I also haven’t seen much discussion of the “set up the paths but don’t load the
whole env” reasoning for boot.rb being separate from environment.rb (mentioned
down-thread by Ryan Bigg). Is this still something useful? If it isn’t, how
will (for instance) Rake tasks that don’t depend on :environment be switched
over?
—Matt JOnes
I also removed the app folder and put directories that were in that folder
in the root. This change was specific to the particular use case I was
designing this for, API-only apps that don't have as much need for the app
distinction.
Once I started thinking about a smaller Rails structure, the idea of the
config folder seemed unnecessary. Anytime I need access to my app's
environment I require application.rb, so to me the distinction between that
and environment.rb doesn't serve much purpose. Given that, why can't
boot.rb be in the root and all the environment config be consumed into
application.rb with a DSL for creating environments like above?
On Tuesday, June 10, 2014 6:50:48 PM UTC-4, Pier-Olivier Thibault wrote:
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.
I think this is somewhat open to discussion. What is the difference between
'bundle exec rails server' and './bin/rails server' besides the longer
command, of course?
I would personally pay the cost of longer commands to see lighter project
file structure as I'm going to spend much more time in the project than I
will executing commands. It's important to note that rake tasks are going to
stay as is.
--
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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [Rails-core] Simplifying `rails new`
On Wednesday, June 11, 2014 3:57:59 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 12:32 PM, Joe Fiorini j...@joefiorini.com
javascript: wrote:
I actually played with simplifying the structure some time ago, although
for a completely different use case. I didn't end up going further than
posting this PoC on Github, but it does actually boot up a Rails app.
My changes:
I moved all application/environment config into a file called
{APP_NAME}.rb. Inside this file I have a module/class definition for the
application the same as any standard Rails app (looks like I accidentally
made it a class rather than Application class inside APP_NAME module,
oops), but I also added a Ruby DSL for specifying environment configs. IME,
the files under config/environments don't normally get a ton of options, so
having them all in one place would actually be easier.
Would this mean smashing all the files in config/initializers into one
file? That would make generators that wanted to create a default
initializer (for instance, the Devise InstallGenerator) much more
complicated since they’d need to insert code into the singular
environment.rb file rather than just drop a whole file into
config/initializers.
I believe it would be the opposite, people, instead of using the
config/initializers/*.rb, they would use mechanics that Rails provides by
default - The initializer method that any railtie class have. Here's an
example of an application.rb file that would include such initializer:
https://gist.github.com/pothibo/a32f686aed0f03729157
I also haven’t seen much discussion of the “set up the paths but don’t
load the whole env” reasoning for boot.rb being separate from
environment.rb (mentioned down-thread by Ryan Bigg). Is this still
something useful? If it isn’t, how will (for instance) Rake tasks that
don’t depend on :environment be switched over?
—Matt JOnes
I also removed the app folder and put directories that were in that
folder in the root. This change was specific to the particular use case I
was designing this for, API-only apps that don't have as much need for the
app distinction.
Once I started thinking about a smaller Rails structure, the idea of the
config folder seemed unnecessary. Anytime I need access to my app's
environment I require application.rb, so to me the distinction between
that and environment.rb doesn't serve much purpose. Given that, why can't
boot.rb be in the root and all the environment config be consumed into
application.rb with a DSL for creating environments like above?
On Tuesday, June 10, 2014 6:50:48 PM UTC-4, Pier-Olivier Thibault wrote:
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.
I think this is somewhat open to discussion. What is the difference
between 'bundle exec rails server' and './bin/rails server' besides the
longer command, of course?
I would personally pay the cost of longer commands to see lighter project
file structure as I'm going to spend much more time in the project than I
will executing commands. It's important to note that rake tasks are going
to stay as is.
--
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-co...@googlegroups.com javascript:.
To post to this group, send email to rubyonra...@googlegroups.com
javascript:.
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.
Re: [Rails-core] Simplifying `rails new`
On Jun 11, 2014, at 3:13 PM, Pier-Olivier Thibault poth...@gmail.com wrote:
On Wednesday, June 11, 2014 3:57:59 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 12:32 PM, Joe Fiorini j...@joefiorini.com wrote:
I actually played with simplifying the structure some time ago, although for
a completely different use case. I didn't end up going further than posting
this PoC on Github, but it does actually boot up a Rails app.
My changes:
I moved all application/environment config into a file called
{APP_NAME}.rb. Inside this file I have a module/class definition for the
application the same as any standard Rails app (looks like I accidentally
made it a class rather than Application class inside APP_NAME module, oops),
but I also added a Ruby DSL for specifying environment configs. IME, the
files under config/environments don't normally get a ton of options, so
having them all in one place would actually be easier.
Would this mean smashing all the files in config/initializers into one file?
That would make generators that wanted to create a default initializer (for
instance, the Devise InstallGenerator) much more complicated since they’d
need to insert code into the singular environment.rb file rather than just
drop a whole file into config/initializers.
I believe it would be the opposite, people, instead of using the
config/initializers/*.rb, they would use mechanics that Rails provides by
default - The initializer method that any railtie class have. Here's an
example of an application.rb file that would include such
initializer:https://gist.github.com/pothibo/a32f686aed0f03729157
In your example, the generator would have to *insert* an additional
`initializer ‘whatever’ do` block into the existing generator. That’s already
going to make things more complicated; finding the appropriate place is not
trivial, especially if the generator needs to play nice with namespaced
applications, such as:
module MyTopLevel
module MyProject
class Application Rails::Application
initializer 'configure devise' do |app|
app.config.devise.somethin = 'blabla'
end
end
end
end
A simplistic strategy (“insert before the 2nd end from the end of the file”)
will fall down here.
More importantly, the *size* of what’s added is significant. The Devise
generator alone drops 260+ lines (mostly comments) to help users configure
things.
The application.rb file seems like it could get quite long, and then somebody
will propose to split it up into, say, a directory of smaller files… :)
—Matt Jones
I also haven’t seen much discussion of the “set up the paths but don’t load
the whole env” reasoning for boot.rb being separate from environment.rb
(mentioned down-thread by Ryan Bigg). Is this still something useful? If it
isn’t, how will (for instance) Rake tasks that don’t depend on :environment
be switched over?
—Matt JOnes
I also removed the app folder and put directories that were in that folder
in the root. This change was specific to the particular use case I was
designing this for, API-only apps that don't have as much need for the app
distinction.
Once I started thinking about a smaller Rails structure, the idea of the
config folder seemed unnecessary. Anytime I need access to my app's
environment I require application.rb, so to me the distinction between
that and environment.rb doesn't serve much purpose. Given that, why can't
boot.rb be in the root and all the environment config be consumed into
application.rb with a DSL for creating environments like above?
On Tuesday, June 10, 2014 6:50:48 PM UTC-4, Pier-Olivier Thibault wrote:
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.
I think this is somewhat open to discussion. What is the difference between
'bundle exec rails server' and './bin/rails server' besides the longer
command, of course?
I would personally pay the cost of longer commands to see lighter project
file structure as I'm going to spend much more time in the project than I
will executing commands. It's important to note that rake tasks are going to
stay as is.
--
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-co...@googlegroups.com.
To post to this group, send email to rubyonra...@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
Re: [Rails-core] Simplifying `rails new`
You are right. However, the initializers is not really what's discussed
here. it's the whole directory structure. Anyway, I think config/ folder
still has its place( and the initializers for all I care). I think the
issue is that over the years, the project structure for Rails has grown to
have a lot of different folder and the meaning of all those folders is not
that obvious. Initializers were never a part of the discussion anyway until
you mentionned it.
On Wednesday, June 11, 2014 6:42:52 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 3:13 PM, Pier-Olivier Thibault pot...@gmail.com
javascript: wrote:
On Wednesday, June 11, 2014 3:57:59 PM UTC-4, Matt jones wrote:
On Jun 11, 2014, at 12:32 PM, Joe Fiorini j...@joefiorini.com wrote:
I actually played with simplifying the structure some time ago, although
for a completely different use case. I didn't end up going further than
posting this PoC on Github, but it does actually boot up a Rails app.
My changes:
I moved all application/environment config into a file called
{APP_NAME}.rb. Inside this file I have a module/class definition for the
application the same as any standard Rails app (looks like I accidentally
made it a class rather than Application class inside APP_NAME module,
oops), but I also added a Ruby DSL for specifying environment configs. IME,
the files under config/environments don't normally get a ton of options, so
having them all in one place would actually be easier.
Would this mean smashing all the files in config/initializers into one
file? That would make generators that wanted to create a default
initializer (for instance, the Devise InstallGenerator) much more
complicated since they’d need to insert code into the singular
environment.rb file rather than just drop a whole file into
config/initializers.
I believe it would be the opposite, people, instead of using the
config/initializers/*.rb, they would use mechanics that Rails provides by
default - The initializer method that any railtie class have. Here's an
example of an application.rb file that would include such initializer:
https://gist.github.com/pothibo/a32f686aed0f03729157
In your example, the generator would have to *insert* an additional
`initializer ‘whatever’ do` block into the existing generator. That’s
already going to make things more complicated; finding the appropriate
place is not trivial, especially if the generator needs to play nice with
namespaced applications, such as:
module MyTopLevel
module MyProject
class Application Rails::Application
initializer 'configure devise' do |app|
app.config.devise.somethin = 'blabla'
end
end
end
end
A simplistic strategy (“insert before the 2nd end from the end of the
file”) will fall down here.
More importantly, the *size* of what’s added is significant. The Devise
generator alone drops 260+ lines (mostly comments) to help users configure
things.
The application.rb file seems like it could get quite long, and then
somebody will propose to split it up into, say, a directory of smaller
files… :)
—Matt Jones
I also haven’t seen much discussion of the “set up the paths but don’t
load the whole env” reasoning for boot.rb being separate from
environment.rb (mentioned down-thread by Ryan Bigg). Is this still
something useful? If it isn’t, how will (for instance) Rake tasks that
don’t depend on :environment be switched over?
—Matt JOnes
I also removed the app folder and put directories that were in that
folder in the root. This change was specific to the particular use case I
was designing this for, API-only apps that don't have as much need for the
app distinction.
Once I started thinking about a smaller Rails structure, the idea of the
config folder seemed unnecessary. Anytime I need access to my app's
environment I require application.rb, so to me the distinction between
that and environment.rb doesn't serve much purpose. Given that, why can't
boot.rb be in the root and all the environment config be consumed into
application.rb with a DSL for creating environments like above?
On Tuesday, June 10, 2014 6:50:48 PM UTC-4, Pier-Olivier Thibault wrote:
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.
I think this is somewhat open to discussion. What is the difference
between 'bundle exec rails server' and './bin/rails server' besides the
longer command, of course?
I would personally pay the cost of longer commands to see lighter
project file structure as I'm going to spend much more time in the project
than I will executing commands. It's important to note that rake tasks are
going to stay as is.
--
You received this message because you are subscribed to the Google
Re: [Rails-core] Simplifying `rails new`
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? 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. 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.
Re: [Rails-core] Simplifying `rails new`
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
Re: [Rails-core] Simplifying `rails new`
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. I think this is somewhat open to discussion. What is the difference between 'bundle exec rails server' and './bin/rails server' besides the longer command, of course? I would personally pay the cost of longer commands to see lighter project file structure as I'm going to spend much more time in the project than I will executing commands. It's important to note that rake tasks are going to stay as is. -- 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.
Re: [Rails-core] Simplifying `rails new`
Replies inline. On 29 May 2014 14:35, Michael Kaiser-Nyman michael...@gmail.com 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. 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.
