--config option on commandline

[denisdefreyne]

Having a --config option on the command line will make it possible to have different environments.

[denisdefreyne]

It will also be necessary to specify the location of the tmp directory—something which I assumed was already implemented, but I was mistaken.

[Fjan]

IMHO a minimal implementation of this comprises these things:

1. A global variable that indicates the environment.
2. A way to switch the output directory for each environment.
3. A way to switch the tmp directory for each environment

It's actually already possible to do all three with the current nanoc (we use it successfully):

1. We simply use something like ENV['NANOC_ENVIRONMENT'], and change the rules in the Rules files with that, but it's probably nicer if something like ::Nanoc.env existed with an optional parameter to the nanoc command to set it
2. The Rules files accepts relative paths, so it's possible to write an output file to 'output/../output_production/...' based on the environment variable. A --config option to use a different yaml file would be nice, but even better would be to do it like Rails and run the nanoc.yaml file through Erb, so you can change the directories based on the environment variable
3. It's a one line monkey patch to the Nanoc::Store class to change the name of tmp dir depending on the environment variable, but it would of course be nice to have a config option for it or even better if it can switch automatically based on Nanoc.env

We wrap the relevant nanoc compile command in custom nanoc commands and rake tasks to set the right ENV variable beforehand. It works well actually, but it would be great if we can do it without monkey patching.

[Fjan]

So a --config option is one way to do it, but an --env option that gets picked up in the nanoc.yaml like rails does it may be even nicer, because there are a bunch of other things you may want to change based on the environment than just the directories. A few examples from our use case:

• The production version uses the CDN for images, the locally compiled output uses local images
• The production version has analytics snippets, the local version does not
• The local version has output from the spell check filter in it, the production version does not
• Pages that are still being worked on are hidden in the production environment

[bburton]

Agree with @Fjan on --env/-e option for specifying an environment name. Those options seem to be commonly used in many Ruby apps including compass which is used with Nanoc by many people. But then there needs to be a way to load the environment specific configuration. It would probably be best to always load nanoc.yaml and if -e/--env is specified or the NANOC_ENV environment variable is defined, then load the specified environment specific name from a file such as nanoc-production.yaml if "production" was specified either way.

The minimalist approach is just to run nanoc.yaml through Erb which would give users lots of flexibility while being extremely simple to implement. What might complement that nicely would be a soft dependency on the dotenv gem (https://github.com/bkeepers/dotenv) which supports importing configuration through an .env file and then pushing it into ENV[].

[gpakosz]

Instead of thinking in terms of solution, ie. --env option. I would rather see Nanoc let options pass through. Then in the preprocess block we could act upon those options.

[majkinetor]

What I currently is to have section like this in nanoc.yaml file:

environments:
    development:
       config1: value1
       ....
       confign: valuen
    test:
       ...
    production:
       ...

and at the top of Rules file I call function set_environment:

def set_environment
    envs = @config[:environments] || {}
    active = ENV.fetch "NANOC_ENVIRONMENT", 'development'
    puts "\n\n|====== ENV: #{active} ======\n\n"
    envs[active.to_sym].each do |k,v|
        @config[k] = v
    end
end

[barraq]

If Nanoc environments existed I would like them to support the following:

• a single nanoc.yaml configuration file like:

  default: &default
      // usual nanoc.yaml content
      text_extensions: ...
      base_url: ...
      ...
  development:
      <<: *default
      base_url: ...
  production:
      <<: *default
      base_url: ...
  yet_another_env:
     <<: *default
      base_url: ...
  

• a support for accessing current active environment in rules.rb, helper and filters in order to:

  • change routing depending on environment
  • filter in/out items. e.g. display all items in development and hide some in production (draft post)

• a support for a per-environment tmp cache and output. Namely what is currently in tmp and output should be moved to tmp/{{ENV}} and output/{{ENV}}

@ddfreyne are you working on it? Do you need help/support?

[denisdefreyne]

With #859 being done, I feel that this issue can now be closed.