-
Notifications
You must be signed in to change notification settings - Fork 68
Let Kaptan pick the handler of it's own choice #22
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
Conversation
|
@arkostyuk Thank you for the contrib. Nevertheless your patch seems to break git-aggregator. Check travis. |
|
ah, yes, didn't really noticed the part that passes a file content to Kaptan directly 🙂 |
1 similar comment
|
@lmignon the build is green now 😉 |
lmignon
left a comment
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.
@arkostyuk Thank you LGTM
|
Looks good. Shall we do a release? @arkostyuk can you suggest a changelog entry? |
|
@sbidoul which version should I target? |
As it is possible to pass a file content instead of a file path to Kaptan, a handler must be resolved before it happens. Though, it's better to make an extra safety step and use Kaptan's own logic to determine a suitable handler than to use bare file extension.
|
@arkostyuk I tagged 1.3.0, it should reach pypi soon |
Since file handler name is being provided directly to
Kaptaninstance, it doesn't try to guess it. Although, it is able to do pretty much the same job of taking the extension from a filename and then using an appropriate file handler to parse stuff - you don't need to be so explicit here :)As a fancy side-effect - for me, git-aggregator has finally started to parse
.ymlfiles properly. I'm aware that there's #14 in amasteralready, but that approach doesn't really solve the issue outside of the autocompletion scope.Kaptan tries to guess the handler here
Currently, providing a
handler='yml'handler directly ends up in aKeyErrorhere