Interactive "rails new"

That sounds like a great idea! If we’re letting you run stuff straight from a URL, we should probably preview what you’re about to run. But do like the idea of expanding the API and making the system itself use it!

5 Likes

Having a rails new --interactive option is a great idea! :+1:

I am also tired of maintaining an ever-growing list of features to exclude :smiley:

For the work I’ve been doing an interactive mode would be more valuable than templates, as every app has different requirements and every team different preferences.

4 Likes

rails new --interactive is really great idea!

It would be really awesome if we have ability to re-add the skipped frameworks. In one of my recent projects, I created the new rails app with rails new my_app --api but later we had to revert the api flag as we also needed rails views in the app.

2 Likes

I have started a draft PR to add support for the new rails command:

rails new --minimal

What exactly are we going to skip? everything… everything?

cc/ @Betsy_Haibel @dhh can someone help make the final call on what exactly is excluded?

Here is the PR:

https://github.com/rails/rails/pull/39282

1 Like

@DHH because there are so many ideas going on in this thread, do you think it would be worth making a Basecamp project or similar to coordinate this work? I think the work-to-be coordinated is fast exceeding what a Discourse thread can support.

I’ve got an idea for adding back gems that were opted-out of:

In the case of core rails gem, like actiontext, we’d simply add install generator that wouldn’t add actiontext to Gemfile (because that’s not needed), but would instead add/uncomment require line to config/application.rb and do any other changes that bin/rails action_text:install does today.

1 Like

Bootsnap has no friction. Devs are neutral because its just there and works. For most aspects, a dev would never realize Bootsnap is even there.

Spring has frictions. Oh you changed an initializer? You better remember to reset your Spring otherwise things won’t behave the way you expect them too (which by the way, why in the hell? I dont remember the details, but i had issues like these). You need to know that Spring exists, and to sometime takes action on it once you realize it is currently messing you up.

This cost of Spring can be offset when there is a good gain from it. Saving n seconds every time you run something is a good way to offset, but if n is too small, say 3 seconds, to me, the cost still outweights the benefit a little bit. When I save 5 to 10 seconds, then it starts to be worth it.

One good thing of Spring is that its easy to install and easy to remove. In my opinion, if Rails started without spring, and when it detected that boot times are slow enough, suggested adding Spring (or tweaking a config somewhere to stop the suggestion), then there would be less hate.

3 Likes

We started this forum in part because that is not true. The ground rules here are that Rails is a big tent. Your experience of Rails may not be someone else’s experience of Rails, and everyone commenting here needs to be respectful of that fact.

Betsy, I’m happy for us to start kicking off issues/PRs for some of these ideas. There’s a clear go-ahead on --minimal and --interactive :+1:

4 Likes

Oh, and also ./bin/rails actionmailer:install along with all the other frameworks you can opt out off with --minimal or --interactive.

5 Likes

Just need a final call on bootsnap, shall we include/exclude?

After that I’m going to start tackling interactive (unless someone has started it already)

I do have some questions around this though.

For a newbie do we want them to add the flag --interactive? For me that does not seem like a nice journey, we have a couple of alternatives:

rails new app_name defaults to interactive

rails new which defaults to interactive

Then we can ask the app name, and every stack they want to include/exclude, skip question or go with the defaults.

EDIT: I’m leaving in bootsnap for now, if you feel otherwise, please let me know!

1 Like

Let’s exclude bootsnap on --minimal; I think that will be principle-of-least-surprise here. Folks who want bootsnap but not the rest of the big modern Rails grab bag can always add it for themselves later.

3 Likes

A big pain point for me is that rails new doesn’t check its inputs in many cases. In others, it provides less feedback than it could. I’d really like an interactive version to model the full domain of rails new options, and give assistance when it’s obviously needed. The current UX is this way because of its architecture of extensive opaque delegation without back-propagation of errors. But we can do things differently in the interactive version.

Examples of UX improvements that we could make in the interactive version:

Silent failure like this should be impossible. Because usually, the mistake is buried in a list of other options, and the incorrect config is discovered much later.

rails new my_app --skip-javascrpt`
      create
      create  README.md
      create  Rakefile
(etc.)

When a user clearly misuses the CLI API like this, we should at least show its synopsis and show how to get help:

$ rails new
No value provided for required arguments 'app_path'

Ditto, because it’s not clear where the app_path should be positioned on the command line:

$ rails new --skip-bundle
No value provided for required arguments 'app_path'
2 Likes

I’d love to have more control in the way rails generates apps.

I’d much rather see this implemented through a config file rather than an interactive installer though.

What would be really magnificent is if you could change your mind at a later date, change the config and run rails install:update to respond to changes

##install.yml

default: &default
#supported options are :none, :sqlite, :mysql, :postgres
  database: sqlite
#supported options are :rspec, :minitest
  testing: rspec
#whether to install active storage and run update the database to support it true/false
  active_storage: true

development:
  <<: *default


test:
  <<: *default


production:
  <<: *default
  database: postgres


just to elaborate on this idea - the issue for me is that I find interactive installers painful to use. They necessarily have to run through a bunch of questions and I have to come up with answers in order.

by contrast - a text file is in some ways the ultimate ‘interactive’ installer. I can open it up in my editor, scan through the things I want to find and read the comments (which could links to explanatory articles)

the flow here would be something like

> Rails new myApp
< Rails has generated an install configuration at ./config/install.yml  
< Please open this in your text editor, adjust as necessary, then run Rails install:update

another advantage of doing this in a file rather than an interactive session is that I can save and re-use the file. With the session, I need to remember my answer to question #7 and repeat it each time.

2 Likes

I think this is an excellent idea. Having a way to re-interrogate these choices later in the day is such a challenging problem to solve, and this gives a neat path forward.

Walter

1 Like

I’d much rather see this implemented through a config file rather than an interactive installer though.

I like this a lot. It scratches all my itches:

  • I can change my mind and install/uninstall something later
  • It documents the options available to me.
  • It allows future-me to clearly see the decisions that past-me has made.

I tend towards a minimalist gemfile, not even installing gems that I know I will need later until I am actually ready to make use of them. This option would be perfect for me along with a --minimal flag.

It seems to me that a config file doesn’t preclude an interactive installer. An --interactive flag could be a good teaching aid for first timers while more experienced devs would likely use the config file.

2 Likes

I like the idea of a config file a lot, although I might suggest something in application.rb itself rather than a yml file.

I think that getting there might take years of refactoring.

What are some small steps that you feel might get the ball rolling on that project?

What are some small steps that you feel might get the ball rolling on that project?

  1. Perhaps rails new could record what it did (and didn’t do) in an install.yml file.
  2. rails new --config=install.yml could make it easy to copy the options from a previous installation.
  3. Overtime, we could add comments to that file to explain how to change a decision manually (for example to switch from mysql to postgres or to add or get rid of turbolinks).
  4. There could be an incremental process of automating some of those choices by editing the install.yml file and running rake install:update. There would probably be some low-hanging fruit but other options might be more difficult.

As you say, Betsy, this might take a while to complete and an awkward period where install:update can update somethings but not others but the first two steps would be valuable on their own.

I was thinking of application.rb (and the Gemfile) as being downstream from this process.

1 Like

Hmm, I think application.rb might be central because I worry about an install.yml approach getting out of sync with the actual application.

I’m open to being wrong here.

I’m trying to think of a good way to do a “tryout” of this idea outside of mainline Rails. It’s difficult, because it’s not a situation where using a gem as the “tryout” vector is a natural fit.

Correct me if I’m wrong, but I see config/application.rb and this install.yml pseudo-script as quite different things? It sounds to me like the .yml is more like “instructions for the generator” whereas app.rb is ‘permanent config’.

I admit I really like the install file idea, and restricting that to app.rb makes it lose its benefits, unless there’s something I’m missing.