A fresh pliny project without models won't start

[gudmundur]

After we merged #287 a freshly created Pliny project won't start without any models. In most cases I think it's fair to assume that a project will have models, but I'd personally prefer if we could start without making code changes.

$ pliny-new my-app
$ cd my-app
$ bin/setup
$ bundle exec rspec
LoadError: empty glob path: /Users/gudmundur/Projects/my-app/lib/models/**/*.rb
  /Users/gudmundur/Projects/my-app/.bundle/gems/pliny-0.22.0/lib/pliny/utils.rb:22:in `require_glob'
  /Users/gudmundur/Projects/my-app/lib/initializer.rb:37:in `block in require!'
...

@cyberdelia @brandur What do you guys think?

[brandur]

Yeah, it definitely seems correct to be able to start without models.

@cyberdelia Was #287 in response to some specific problem that you saw in your projects? I wonder if there's a different way that we could solve it.

[cyberdelia]

The idea was to avoid initializer.rb to grow and and point to paths that are not existing anymore. We could probably have a require and a require!?

[halorgium]

@cyberdelia @brandur could the model generator remind the user to add the require line if it doesn't exist? i encountered this recently and resolved it by making a model, but i could imagine starting a prototype without any models at all.

[brandur]

@cyberdelia @brandur could the model generator remind the user to add the require line if it doesn't exist? i encountered this recently and resolved it by making a model, but i could imagine starting a prototype without any models at all.

Yeah, good question. This certainly seems like kind of a bad state to leave the project in.

I'm not super crazy about just adding some kind of note just because I feel like most scripts have enough output these days that users are more or less acclimated to ignoring them.

What do you guys think about adding an allow_empty: false optional parameter to require! that would appear as allow_empty: true in the default template? That would allow the project to start with an empty set of models, but also allow advanced users to just remove that argument to make their stack somewhat safer in the event of refactorings.