pod search and lib lint are not working with a pod that contains "+" in its name anymore (since 0.34)

[fcy]

I've a private pod that I use to override a macro in an existing public pod, so to differentiate I added "+Logger" to it. It was working flawlessly until I updated to 0.34.2 (not sure if happens on 0.34.1).

$ pod search FCYAsserts+Logger
[!] Unable to find a pod with name matching `FCYAsserts+Logger'

$ pod lib lint
[!] Unable to find a specification for `FCYAsserts+Logger` depended upon by PrivatePod/Core (1.1.alpha).

But if I remove the suffix pod search finds the pod:

$ pod search FCYAsserts


-> FCYAsserts (1.2.2)
   Collection of assert macros that logs useful messages.
   pod 'FCYAsserts', '~> 1.2.2'
   - Homepage: https://github.com/fcy/FCYAsserts
   - Source:   https://github.com/fcy/FCYAsserts.git
   - Versions: 1.2.2, 1.2.1, 1.2.0, 1.1.0, 1.0.1, 1.0.0 [master repo] - 1.2.2, 1.2.1, 1.2.0, 1.1.0, 1.0.1, 1.0.0 [master-1 repo]


-> FCYAsserts+Logger (1.2.2)
   Collection of assert macros that logs useful messages.
   pod 'FCYAsserts+Logger', '~> 1.2.2'
   - Homepage: https://github.com/fcy/FCYAsserts
   - Source:   https://github.com/fcy/FCYAsserts.git
   - Versions: 1.2.2 [private repo] - 1.2.2 [private-1 repo]

[segiddins]

@fcy are you running CocoaPods 0.34.2?

[fcy]

@segiddins yes

[segiddins]

@fcy the issue with pod search is that the QUERY is a regex, where + is a special character.

[fcy]

Is this closed as won't fix? It is not just search that is broken, pod lib lint is also.

Being a regex I should be able to scape "+" which doesn't work:

$ pod search FCYAsserts\+Logger
[!] Unable to find a pod with name matching `FCYAsserts+Logger'

[segiddins]

try enclosing the query in quotes.

Can you please provide more details on what's wrong with the behavior of pod lib lint, preferably using public pods so we can fix it?

[fcy]

Enclosing it in quotes worked. Be right back with a public sample that reproduces the problem with pod lib lint.

[fcy]

@segiddins turns the pod lib lint problem is not related to the "+" character. I've created a new issue: #189

My 2 cents on the "+" issue, there are a lot of pods that contains it. I think pod search should scape + by default because it is counter intuitive to have to quote and space while searching for such a common pod name.

[segiddins]

@fcy escaping + would mean that you couldn't do regex searches

[AliSoftware]

@segiddins I agree with @fcy : we have a lot of pods with + in their name (especially in our private pods repo) and I know a lot of ppl that don't understand why they don't show up when trying to find them with pod search, believing it is a bug, not a feature.

My suggestion:

• defaults to fulltext matching (or escaping the query given in the command line before passing it to the regex)
• provide a --regex or similar flag to allow regex searches

I have to admit that only a few of us use the regex ability when using pod search, so making it optional and defaulting to a more intuitive fulltext search makes sense IMHO, while still keeping the possibility using an option.

[alloy]

I agree with @fcy and @AliSoftware on this.

[AliSoftware]

BTW why is this issue in CocoaPods/Core?

[kylef]

@AliSoftware It does belong in CocoaPods. Feel free to move it over.

[AliSoftware]

Note that I'll also modify Pod::Command::Spec#get_path_of_spec (used by pod spec which, pod spec cat and pod spec edit)… so that those commands interpret their argument as plain text and not Regexp… as it was always expected according to those methods documentation and those command usage description.

--- a/lib/cocoapods/command/spec.rb
+++ b/lib/cocoapods/command/spec.rb
@@ -338,7 +338,7 @@ module Pod
       # @return [Pathname] the absolute path or paths of the given podspec
       #
       def get_path_of_spec(spec, show_all = false)
-        sets = SourcesManager.search_by_name(spec)
+        sets = SourcesManager.search_by_name(Regexp.escape(spec))

[AliSoftware]

Closing this as the PR to fix this is ready to be merged.