Allow .yml as well as .yaml

[mitom]

Could you allow using .yml as well as .yaml for the configuration files? I'd say they are equally common and they are both valid. .yml files are simply ignored at the moment.

[jamesroutley]

Hey @mitom we've decided to not support .yml extensions. We currently use the filesystem to guarantee name uniqueness, and we can't do that if we support .yml and .yaml.

Imagine you have:

.
└── config
    └── dev
        ├── vpc.yaml
        └── vpc.yml

And you run sceptre launch-stack dev vpc we'd have no way of telling which one you wanted.

We went with .yaml because it's the official extension.

[mitom]

It being the official extension is a good point, I wan't aware of there being a preference! However, it's so commonly interchanged (https://github.com/cloudreach/sceptre/blob/master/circle.yml 😛 ) I would expect it to work as well. Alternatively, a friendlier error for not finding a stack:

sceptre create-stack dev common
Traceback (most recent call last):
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/bin/sceptre", line 11, in <module>
    sys.exit(cli())
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/lib/python2.7/site-packages/click/core.py", line 716, in __call__
    return self.main(*args, **kwargs)
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/lib/python2.7/site-packages/click/core.py", line 696, in main
    rv = self.invoke(ctx)
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/lib/python2.7/site-packages/click/core.py", line 1060, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/lib/python2.7/site-packages/click/core.py", line 889, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/lib/python2.7/site-packages/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/lib/python2.7/site-packages/sceptre/cli.py", line 93, in decorated
    return func(*args, **kwargs)
  File "/Users/tamasmillian/.pyenv/versions/2.7.12/lib/python2.7/site-packages/sceptre/cli.py", line 243, in create_stack
    response = env.stacks[stack].create()
KeyError: u'common'

(the error above is due to me naming the config common.yml instead of common.yaml)

As for uniqueness, It seems easy to validate uniqueness based on the filename - ignoring the extension - and throwing an error or falling back to the yaml as a the preferred one due to it being the official extension?

[theseanything]

I'd say if this did get implemented, I'd lean towards throwing duplicate stack config exception. To be explicit and prevent any confusion over which file was being used.

[jamesroutley]

I think the thing to do for now improve the error thrown when .yml is used. We can search config/ for .yml files and throw an error warning the user that the .yaml extension should be used.

Allowing either and throwing an error if a duplicate is found could lead to issues. If two projects were happily using .yml and .yaml respectively, and wanted to share code, the difference in extensions could lead to issues avoided if we push everyone to use the same extension.

Also, I think think this issue may become redundant if we implement #62 in v2.

[theseanything]

@jamesroutley could you elaborate on the error you could see happening when code is shared?

Tbh, another reason this hadn't been done, was it was low priority and we were trying to keep maintainability - Implementing throwing an exception to warn .yml being used kinda negates this.

[jamesroutley]

so if you have any .yml file under config/ (i.e. config/**.yml), we throw e.g. an UnsupportedTemplateFileTypeError which says File x.yml has an unsupported file extension. Please use .yaml

@galbinasu and I looked at the implementation the first time this issue was raised (on BitBucket) and we decided that it wasn't worth adding support for the uniqueness reason mentioned in my first post. If we only have one extension, we defer uniqueness checking to the filesystem. If we have both, we have to implement it ourselves.

[theseanything]

@jamesroutley sorry I meant what issues do you see happening when code is shared, like you mentioned. (Not the error about unsupported file extension). Not sure I see the disadvantages...

Right - but if we are going to have implement something either way - if we throw a UnsupportedTemplateFileTypeError or we throw a DuplicateConfigurationFileError. Amount of code/logic probably is about the same.

[mitom]

@jamesroutley #62 would help some but definitely wouldn't solve it. The --recursive option will error on missing stacks - or not do anything, I am not sure - for .yml files. The autocomplete would provide visibility, but it will happily complete to path/to/stack.yml as implying it's a valid input.

I don't see how shared code or collaboration would cause errors with this, in case 2 projects are merged (or partially merged) there are definitely more work to be done than renaming 1 file and changing the resolver for some parameters to avoid the duplicate.

I understand the aim for simplicity, but I still disagree on behalf of pretty much everything else supporting .yml as an interchangeable extension for .yaml.

[jamesroutley]

@seanrankine sounds good - let's go with that. So when we search for stacks we'll look for (.yml|.yaml) and throw an error if a directory contains a .yml and .yaml with the same basename?

[theseanything]

Yup!

[JuanCanham]

I know this is an old thread, but can we close as will not implement?

.yaml is the "correct" extension as per http://yaml.org/faq.html and most of the workarounds are quite hacky

[ngfgrant]

Yeh I agree @JuanCanham. It is not a priority at the moment, I will make sure it is clear in the docs to use .yaml and not .yml.