Ideas for scaffolding

[andrewthad]

I have a branch here: https://github.com/yesodweb/yesod-scaffold/tree/postgres-no-compile-time-settings-no-devel

This is basically a fork of the scaffolding that has emerged as a result of me pulling in the common code that I needed to add to all of the apps I've built at work. I don't expect that this should replace the existing scaffolding for everyone (some of the ideas are probably too specific to my workflow), but I think that it's probably a good source of ideas. The README is pretty explanatory of the customizations I've made. If anyone finds them interesting or has any comments or questions, I'd like to hear feedback. In particular, I feel like the good changes are:

• Not reading settings.yaml at compile time
• Scaffolding of Task-related things (type Task x = ReaderT App IO x)
• Cronjob scaffolding
• Moving source files into src

[gregwebs]

rather than moving source files into src I would like to move things into an application-specific name space. Reason being that we have multiple Yesod apps where I work and it would be nice to have a global ghci namespace that avoids conflicts.

[gregwebs]

• I really like the way the current settings work (including with respect to compile time).
• I don't use Keter, but no reason why users cannot just delete it.
• Most sers should define their own Prelude on top of classy-prelude
• better bootsrap support seems good
• we shouldn't encourage a Misc junk drawer: imports and definition locations should be well organized. I generally end up using Import.NoFoundation as a junk drawer for a few things until I have enough to move them out

[gregwebs]

supporting cron is good.
but mixing in cron deployment logic with the app doesn't work for everyone

The concept of a Task, is good. Often I see this referred to as a Job

What I have done before is provide a defaultLayout for the app but modify the layout for the error cases. Either way we should make this easier

[gregwebs]

see this issue for scaffolding improvement: yesodweb/yesod#997
I would like to start moving forward on some of these

[andrewthad]

Thanks for the feedback. I totally agree that most of the things I changed are not appropriate for most users. I could put up a PR for the Task module (I'll name it Job instead) and type synonym, since that seems to be something we're in agreement on.

[andrewthad]

Also, I wanted to clarify what I find confusing about the compile-time settings. There is a config/settings.yml file, and it starts with these lines:

static-dir:     "_env:STATIC_DIR:static"
host:           "_env:HOST:*4" # any IPv4 host
port:           "_env:PORT:3000"
approot:        "_env:APPROOT:http://localhost:3000"
...
reload-templates: true # I explicitly set this to true for this example

When I deploy an application to prod, I want to change the approot. Cool. I could set the environment variable or just do it manually in the settings file:

approot:        "http://my.service.com"

On production, I don't want template reloading. So, it would seem natural to do this:

reload-templates: false

But, this doesn't work because the runtime value of this setting is never actually used. The main issue that I have is not that compile time settings are pulled from a yaml file. It's that they are alongside runtime settings in the same file. I think that a separate file with the compile time settings would make more sense.

[gregwebs]

Seems better documentation of settings is needed?
In production, by default all of the config file settings are sourced at compile time as an opaque JSON Value. At runtime env variables are first applied and then the opaque Value is converted into a settings data type.