Skip to content
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

Podspec can't use utf-8 without lint failure #108

Closed
febeling opened this issue Apr 11, 2014 · 4 comments
Closed

Podspec can't use utf-8 without lint failure #108

febeling opened this issue Apr 11, 2014 · 4 comments

Comments

@febeling
Copy link

Ruby uses a magic comment in the first line of the file to specify the encoding of the file. Otherwise ASCII is assumed.

To specify utf8, a comment like this is put into the first line of the source file:

# -*- coding: utf-8 -*-

When running pod lib lint on this, a warning is issued and the lint fails. This is the output:

$ pod lib lint
-> Pixltag (0.1.0)
    - WARN  | Comments placed at the top of the specification must be deleted.

[!] Pixltag did not pass validation.
You can use the `--no-clean` option to inspect any issue.

I don't think this is very helpful. Non-ascii names are impossible to use then.

@orta
Copy link
Member

orta commented Apr 11, 2014

we can probably remove that comment check pretty soon entirely with the upcoming specs repo changes.

@alloy
Copy link
Member

alloy commented Apr 11, 2014

It shouldn’t even matter in the case of a podspec, as we don’t use require/load. Instead we always read the file as UTF-8 and then eval the source.

Did you encounter a real problem?

@alloy alloy closed this as completed Apr 11, 2014
@febeling
Copy link
Author

My editor, emacs, inserts an encoding comment there automatically when editing ruby. If you choose to out rule that and only accept an arbitrary subset of ruby syntax with your linter, that's your design choice.

@alloy
Copy link
Member

alloy commented Apr 11, 2014

@febeling I see. I guess what @orta says makes sense, we can soon remove the check anyways.

@alloy alloy reopened this Apr 11, 2014
Ashton-W pushed a commit to Ashton-W/Core that referenced this issue Nov 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants