include_path vs include_paths

[mortenpi]

For setting the include paths, the documentation

Sass.jl/src/julian_api.jl

Line 35 in f627a99

- `include_paths` (`AbstractString` or `AbstractArray{<:AbstractString}`)

disagrees with the implementation

Sass.jl/src/julian_api.jl

Line 11 in f627a99

:include_path => sass_option_set_include_path,

As libsass seems to have s at the end, I guess the implementation should be changed to :include_paths => sass_option_set_include_paths?

[piever]

If I remember correctly, the rationale was that the C API has include_path to pass one string (of either one path, or many "colon separated" paths), and include_paths to pass an array of strings. At least, that's what I understood from reading here. At the time I thought that this API was a bit odd.

Possible options:

1. Stick to C API and have different keywords for one string or many
2. Choose include_path for both one string or many
3. Choose include_paths for both one string or many
4. Allow either include_path or include_paths for both one string or many

Which makes the most sense to you? I suspect 3 is the Julian way, as in the case of "one or many" the default is the plural. OTOH it may be not ideal to have include_paths and plugin_paths, but input_path and output_path.

[mortenpi]

Sorry for forgetting to reply to this. My feeling is that since the keyword is directly related to the sass_option_set_include_path function, it would make sense to keep it include_path.

I didn't read the C code, but looking at the C API, my hunch is that include_paths is just an internal helper variable and is kept synced with include_path. As far as I can tell, include_path can contain either a single path or many (colon-separated) and in either case you should set it with sass_option_set_include_path.

[piever]

Makes sense, I also prefer changing the documentation rather than the implementation. Thanks for making the PR!