VERSION file

[segiddins]

Now that all the specs are evaluated and serialized to JSON, I vote for making the default spec's version read from a VERSION file in the root of the project, and basing the rake tasks off of that. Thoughts?

[fabiopelosin]

I definitely prefer to serialise versions in dedicated files as it makes programmatically changing them much easier.

[segiddins]

Awesome. I'll handle the migration later this week.

[BennettSmith]

This change is causing a "pod install" from within the Example folder to fail. The line that reads the VERSION file in the podspec fails. It seems like a bad idea in general to have a podspec make an assumption about the location of the VERSION file. How will this work with development pods?

Perhaps the Rakefile should actually write the updated version number into the podspec instead of trying to read it from the VERSION file.

[AliSoftware]

Perhaps the Rakefile should actually write the updated version number into the podspec instead of trying to read it from the VERSION file.

As already previously discuted, this would be very hard to implement. A podspec is a Ruby source file, and users can do whatever they like in their podspec as long as it produces a valid Podspec Ruby object. They can put the version in a temporary Ruby variable and use this variable in their s.version entry of the Podspec, they can compute/compose the version string dynamically…

And for the associated tag it's worse, as they can use a variable too or compute it too, or use :tag => s.version.to_s (that's exactly what I personally do in my own podspecs)… and they can also write this :tag hash key either in the same like as s.source on in a separate line…

That would be quite a hell for a Rake task to update such a podspec in a safe manner without breaking anything. Quite a nightmare to implement, don't even think about it.

[BennettSmith]

Yes, I agree completely. But, the recent change to have the podspec read in the VERSION file seems to completely break the use of private pods and development pods. Am I missing something? Right now if you create a new pod using this template and then setup a project in the Example folder that references the podspec file in development it will result in an error when "pod install" is invoked.

My suggest about having the Rakefile update the podspec was just that, a suggestion. I don't really like it. I don't like the idea of having the podspec contain the File.read('VERSION') line either. If the version of the pod is going to be maintained in the VERSION text file and used by the Rakefile then a better solution needs to be provided for injecting the version number in to the podspec. The current approach is broken.

[AliSoftware]

agreed.

[wilg]

This seems to also break referencing a local Pod for me too, because the podspecs are copied without the associated version file.

Running pod install when the Podfile has path: set results in this:

[!] Invalid `CocoaLUT.podspec` file: No such file or directory @ rb_sysopen - /Users/wil/Code/Lattice/Pods/Local Podspecs/VERSION. Updating CocoaPods might fix the issue.

[wilg]

The workaround I am using to enable development is this:

s.version = begin; File.read('VERSION'); rescue; '9000.0.0'; end

Which is very not ideal.

[segiddins]

@AliSoftware / @irrationalfab I think what we really should be doing is generating a JSON podspec and putting that in the local pod specs dir. Thoughts?

[kylef]

@segiddins That would solve the problem. But this could then break dynamic Ruby podspec's when using :path.

[AliSoftware]

@segiddins I'm reserved about that. Storing the JSON podspec in the local podspecs dir (= ~/.cocoapods/repos/xxx) would solve the problem, but I really don't want the podspec stored at the root of the source repo (alongside the source code) to be JSON. Because I use dynamic ruby code quite a lot in my podspecs (well not that much, but I would really miss it if we are forced to switch to JSON even locally).

And the pod-template is all about creating a pod template project with its associated podspec stored locally (with the podspec only sent to the local podspec dir or the trunk using either pod trunk push or pod repo push). So the task that would be supposed to edit the podspec to bump the version must still have to deal with the local podspec file, which must still be possible to be Ruby.

[kylef]

A better fix would be to evaluate the pod spec ruby from the directory it's from (in this case the :path).

[segiddins]

Agree with @kylef

-Samuel E. Giddins

On Jun 17, 2014, at 5:56 AM, Kyle Fuller notifications@github.com wrote:

A better fix would be to evaluate the pod spec ruby from the directory it's from (in this case the :path).

—
Reply to this email directly or view it on GitHub.

[alloy]

Agreed as well.