-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERB suffix handling #114
ERB suffix handling #114
Conversation
Fixing those complaints would require using an external library.
cc @james-powis @puppetlabs/modules @puppetlabs/sdk |
All in all everything looks pretty concise and certainly a good cleanup of the code base. Per your description "prefer .erb in filename" certainly looks like it is required, none of the tests (or the code as I am interpreting it) allow for backward compatibility for non-.erb suffixed in module root. Was that the intention? |
right, I went back on that decision last minute, and never added a test for
that. I probably also need a negative test for the case this does not
support (i.e. .erb suffix in config keys)
…On 21 April 2017 at 15:40, James Powis ***@***.***> wrote:
All in all everything looks pretty concise and certainly a good cleanup of
the code base. Per your description "prefer .erb in filename" certainly
looks like it is required, none of the tests (or the code as I am
interpreting it) allow for backward compatibility for non-.erb suffixed in
module root. Was that the intention?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#114 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABsQLz9G7AUzJ6IgMQV30ujIJIDLlvtks5ryL_IgaJpZM4NEXue>
.
|
I am really concerned about the level of work required by the community and members outside the community who leverage modulesync who are going to have to refactor because of this... it does not add much complexity to support non-.erb suffixed files, is there any way we can keep that logic but insist on the absence of .erb in the associated config files? |
https://github.com/voxpupuli/modulesync/pull/114/files#diff-94f12d4c397c9e0adbe4eb57f1c8dcbeR13 still allows non-erb suffixed templates. Fixing a template is as easy as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve the changes. However, I'd like some concurrence before merging, at least another set of eyes to ensure it is considered properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a test for the deprecated code path, where no ERB extension is given to the file in moduleroot/
? Otherwise I think I'm OK with the change.
#93 changed modulesync to allow for .erb suffixed templates. In many cases this is useful to avoid the template being interpreted as the real thing by other tooling, like e.g. a `.gitattributes` file. As discovered around #113, the original fix was not complete, and e.g. failed when being combined with `:global` sections. This commit now moves more towards always using `.erb` suffixes on template's names, and - for readabilitie's sake - only look for un-adorned keys in the config files. Closes #113
Merged, thanks @DavidS. |
The README still says:
This is now incorrect, right? Also, the section title now seems weird. Maybe it should it better say:
PR? |
No description provided.