Cocoapods: Unrecognized 'swift_version' key

[kenworley]

• [x] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

pod spec lint -> passes
pod lib lint -> passes
pod trunk push -> FAILS

What did you expect to happen?

successful publication of new version of pod

What happened instead?

error reported:

-> "{\"error\":\"The Pod Specification did not pass validation.\",\"data\":{\"warnings\":[\"Unrecognized swift_version key.\"]}}"
read 116 bytes
Conn keep-alive
[!] The Pod Specification did not pass validation.
The following validation failed:

• Warnings: Unrecognized swift_version key.

Note: I haven't changed the swift_version key through the last few versions of the pod.
Also tried from two different computers - same error.

CocoaPods Environment

Stack

   CocoaPods : 1.6.1
        Ruby : ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin18]
    RubyGems : 2.5.2.3
        Host : Mac OS X 10.14.3 (18D109)
       Xcode : 10.1 (10B61)
         Git : git version 2.17.2 (Apple Git-113)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ c804ac110760771f335b810c3533e4d2da92bc00

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-deintegrate : 1.0.2
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.1
cocoapods-try         : 1.1.0

Project that demonstrates the issue

WrapModel

[dnkoutso]

Are you using 1.7.0? I know there was a warning for it.

[GrumpyKir]

I'm using 1.5.3 and I have the same issue

[dnkoutso]

There is a workaround available with --allow-warnings for you.

[kenworley]

I'm using 1.6.1

[kenworley]

Oddly, I pushed several previous versions with this same pod version and they were fine. This error seems to be generated from a remote call. From verbose output:

<- "POST /api/v1/pods?allow_warnings=false HTTP/1.1\r\nContent-Type: application/json; charset=utf-8\r\nAccept: application/json; charset=utf-8\r\nUser-Agent: CocoaPods/1.6.1\r\nAuthorization: Token 33b79e466144a8c94c7115c2a4d97434\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nHost: trunk.cocoapods.org\r\nContent-Length: 474\r\n\r\n"
<- "{\"name\":\"WrapModel\",\"summary\":\"WrapModel is a data model class providing access to JSON formatted model data in string or dictionary form.\",\"version\":\"1.0.4\",\"platforms\":{\"ios\":\"10.0\"},\"requires_arc\":true,\"swift_version\":\"4.2\",\"license\":{\"type\":\"MIT\",\"file\":\"LICENSE\"},\"authors\":{\"Ken Worley\":\"[email protected]\"},\"homepage\":\"https://github.com/1stdibs/WrapModel\",\"source\":{\"git\":\"https://github.com/1stdibs/WrapModel.git\",\"tag\":\"1.0.4\"},\"source_files\":\"WrapModel/*.{swift}\"}\n"
-> "HTTP/1.1 422 \r\n"
-> "Date: Mon, 25 Mar 2019 13:00:19 GMT\r\n"
-> "Connection: keep-alive\r\n"
-> "Strict-Transport-Security: max-age=31536000\r\n"
-> "Content-Type: application/json\r\n"
-> "Content-Length: 116\r\n"
-> "X-Content-Type-Options: nosniff\r\n"
-> "Server: thin 1.6.2 codename Doc Brown\r\n"
-> "Via: 1.1 vegur\r\n"
-> "\r\n"
reading 116 bytes...
-> "{\"error\":\"The Pod Specification did not pass validation.\",\"data\":{\"warnings\":[\"Unrecognized `swift_version` key.\"]}}"

[kenworley]

Ah, didn't realize you meant me. Successful push with --allow-warnings
Thanks for that @dnkoutso

[RastislavMirek]

This is a serious issue, makes cocoapods feel broken and unreliable. Reproduces on every push. Costs a lot of time to find this thread. Please fix ASAP.

[molind]

Stuck on the same issue during publishing GLMapSwift.

[dnkoutso]

There is currently a workaround available. We are weighing in the option of adding 1.6.2 support for swift_versions DSL...don't think it will happen right now but I am also pushing ahead on 1.7.0

[tonystone]

@dnkoutso what are the effects of using --allow-warnings on the end user who will use my project. For one of my own projects, StickyEncoding, the swift_version is required to build and is also listed in the Podspec.json file which is published.

---

Update: Should have been more specific, I am using CocoaPods 1.6.1 and would like to continue to publish with that until 1.7.0 goes production.

[dnkoutso]

1.7.0 can parse swift_version and swift_versions keys in the JSON as it is backwards compatible.

1.6.1 is not forwards compatible so a version published with 1.7.0 will pluralize the DSL which is what this GH issue is.

The negative effect of --allow-warnings is that your pod will still be published even if it has compiler warnings for example. Basically --allow-warnings does not distinguish between compiler warnings _or_ CocoaPods linting warnings such as the one presented here. Its a workaround.

I am actually shipping 1.7.0.beta.3 today to fix https://github.com/CocoaPods/trunk.cocoapods.org/issues/257 then I will resume decision here.

[1ec5]

1.6.1 is not forwards compatible so a version published with 1.7.0 which will pluralize the DSL which is what this GH issue is.

Note that pluralizing the DSL makes the pod incompatible with 1.6.1 (#8637). Per the discussion there, it isn’t recommended to push a pod with 1.7.0 until it comes out of beta.

[chrisballinger]

It seems like 1.7.0 should publish with both keys swift_version and swift_versions in the JSON, to retain backwards compatibility with 1.6.1.

If multiple versions are specified in swift_versions, perhaps the highest could be copied over to swift_version in the JSON.

[lilyball]

I could have sworn the plan for the new swift_versions support was to populate both the swift_versions and the swift_version key. I'm really annoyed to see this didn't happen, as I just pushed a new pod last night using the 1.7 beta and didn't realize I was breaking compatibility with 1.6.1.

[paulb777]

One option to make the compatibility problem easier to see is to use the cocoapods_version attribute in podspecs.

[dnkoutso]

Fix for this is in cocoapods core and will be under review. Expected to be included in 1.7.0.rc.2

https://github.com/CocoaPods/Core/pull/537

[realityworks]

Broken for me as of May 14th - cocoapods version -> 1.6.1... Seems like a fundamental issue with being able to add pods. Is there a work around for this?

[dnkoutso]

We will be merging the PR above and potentially preventing trunk pushes for versions <= 1.7.0.rc.1 and release 1.7.0.rc.2

[JanNash]

And until then, if it's really urgent, I guess you could use the --allow-warnings flag and cautiously check your compiler warnings manually, so you don't publish a possibly broken release.

[dnkoutso]

Hey all. Apologies for this issue lingering longer. We have merged a fix in which 1.7.0 publishing will include a swift_version (singular) key in the JSON so old versions can continue to function.

We will be shipping 1.7.0.rc.2 in the following days and then block publishing of podspecs in versions equal or less to 1.7.0.rc.1 (edit: within 1.7.x) to prevent this issue from happening.

[lilyball]

When you say blocking, are you going to block podspecs published by 1.6.x and below as well? Because it seems like a bad idea to require the use of a non-GM version for anything. I strongly recommend blocking only 1.7.0 versions less than 1.7.0.rc.2.

[dnkoutso]

Yes I meant 1.7.0 versions only.

[dnkoutso]

1.7.0.rc.2 with the fix has been released. We are updating trunk to reject podspec pushes in 1.7.0 betas and < .rc.2.

[dnkoutso]

Trunk PR https://github.com/CocoaPods/trunk.cocoapods.org/pull/263