linter is allowing whitespaces in subspecs

[mmacvicar]

This commit 17aaae0 recently changed a validation to make the version optional in the string representation. However, it also started enforcing something that was not being checked there.

The old regexp was matching anything that ended in non-whitespaces and a version (ignoring the a any prefix that included whitespaces):
/(\S_) ((._))/
The new one does not allow that (which is the right thing):
/\A(\S*)(?: ((.+)))?\Z/

The problem is that the current linter checks for whitespaces in the spec name but it does not check that for the subspecs.

For example:
https://github.com/CocoaPods/Specs/blame/4a2a7d017cddfdec782da5bbdd2abee353549280/Specs/mopub-ios-sdk/2.2.0/mopub-ios-sdk.podspec.json

That podspec passes linter validations and works fine during a fresh pod install but an exception is raised in the next pod install or pod update:

[!] Invalid string representation for a specification: mopub-ios-sdk/MoPubSDK Internal (2.2.0). The string representation should include the name and optionally the version of the Pod.

I would be happy to send a patch but first I wanted to verify that having "MoPubSDK Internal" as a subspec name is indeed not allowed.

[segiddins]

@kylef / @fabiopelosin please confirm that subspecs can't include spaces?

[alloy]

@segiddins I think it should be consistent with root specs. Is there a good reason to not have spaces in those names? If so, then let’s apply the same to subspecs.

[mmacvicar]

@alloy I understand spaces are not allowed in root specs, there is a linter spec called "'fails a specification whose name contains whitespace".

[fabiopelosin]

White space was not supported because it could create issues with the integration (mostly with XCConfigs). Those areas of CocoaPods have been greatly improved so it might be feasible to allow specs with space in the root of the Pod. However I'm not sure wether that is a desirable thing.

Subspecs should just follow the policy for root specs. Accordingly the regex change naively backed on this assumption without realising how many subspecs relied on this behaviour.

[segiddins]

@kapin would appreciate hearing your thoughts on this

[joshkalpin]

Is there any possible way to make a subspec a "spec" object and just pass it to the linter? That might be the way to do it. I need some time to properly look at how subspecs are handled though because it has been a while.