Adding dependency manager for addons to Openframeworks

[minusplusminus]

Hello,

I would like to know what the opinions are about using cocoapods to manage dependencies on osx/ios.
Cocoapods has the possibility to switch sources. The Openframeworks git could be used and Cocoapods could strip-down the parts that doesn't have to be used. Adding addons with the latest versions is going to be allot easier. And the possibilities of Openframeworks versions, like 64 bit build, cpp11 would be easier to use.

People allready created podspecs for OpenCV, BOOST, POCO...

I know that apothecary exist, but i'm not convinced that that is a good dependency manager. I don't know if there's a better choice or even a multi-platform possibility. So i'm open to more input.

[pizthewiz]

Thanks for clarifying the question in your edit. My initial impression is that I'm not quite sure what problem using cocoapods would solve, as supporting C++11 / x86_64 on OS X isn't as simple as updating the dependencies and binary OF release users don't directly interact with the source/binary dependencies included in OF as it is. OF targets many platforms, in many cases uses specific library versions (or even forks) and they are often built with specific settings (try getting cocoapods to build OpenCV with a libstdc++ i386 slice and c++11 / libc++ x86_64 slice for OS X).

[minusplusminus]

When I first used Openframeworks a few years ago. The main problem I had was finding and using addons. But still I have difficulties with it. When I want to use OpenCV 2.4.9 combined with an iOS device. For me it's a half day of work to get it fixed. The simplicity of creating a file that prepares your workspace is something that would simplify the process. It's written in Ruby, so forking it, rebranding it to OFPod and adding Linux/windows functionality could be a possiblity.

[kylemcdonald]

just want to agree with @minusplusminus that dependency management for OF is super important -- but also with @pizthewiz that OF is aimed at a lot of platforms. that said, there are a lot of "unofficial" but important tools, like https://github.com/admsyn/OFPlugin which are platform specific but very commonly used. so there's always space for platform specific things :)

@minusplusminus the ideal solution to your opencv 2.4.9 + iOS issue, i think, is for OF to have a shorter release cycle, and to keep binaries up to date, building them regularly with apothecary scripts. if you have a chance, it'd be great if you could take a look at the apothecary script for opencv + ios and see if you can contribute anything there.

[minusplusminus]

There's a new one: https://www.biicode.com/

[admsyn]

IMO the benefit is pretty marginal for the amount of work it'd add, maintenance etc. Can you give a specific example of a use-case @minusplusminus ? I realize it'd be for "managing dependencies", but that could actually mean many things in the context of OF.

Are you talking specifically about automating the process of keeping an addon's internal library up to date, from the perspective of a person writing an OF app?

[cerupcat]

Have we considered having a podspec for at least all of openFrameworks (top level)? That'd be great (IMO) for iOS users. Then optionally in the future we could have OF 'core' and then sub specs for addons on things like that. For example, in my projects I don't really need ofxOpenCV which is several hundred mb. It's be nice to only have the things you need included (but that's secondary) to be able to manage versions using cocoapods for OF as a whole.

[johndpope]

I suggest using a gist to get this started on gist.github.com.
There's a bunch of overhead maintaining cocoapods and bumping versions which is a reason why carthage has gained in popularity - but there's a less heavy road where you point podfile to a specific git commit.

If it's not clear of benefits -
with any ios project online - if there's a Podfile included
by running Pod install
all the files will be checked out and you can then run the project.
It's very simple - no need to change / fix / update search paths etc.
You can also peg the cocoapods version using a Gemfile which allows backward compatibility / so things don't break.

The Podspec file should resemble something like this (NOT WORKING)
https://gist.github.com/johndpope/80936522226fe06c27c28fb1be2624ef

Once this is working - (it's not - I just did a crude find and replace against the opencv)
then people can quickly start open cv projects with xcode on mac without jumping through so many hoops.

[johndpope]

not sure why cocoapods couldn't be used here with a bit of tenacity - cocoapods recently supported static binaries - CocoaPods/CocoaPods#6651

Imagine the following -
I want to use openFrameworks for ios project

I create a Podfile with
pod 'openFrameworks'

then simply issue
pod install

this then downloads a zip file with prebuilt binaries
like this
"http": "https://github.com/audiokit/AudioKit/releases/download/v3.7.1/AudioKit.framework.zip"

https://github.com/AudioKit/AudioKit/blob/master/AudioKit.podspec.json

[transat]

Here's an idea...

1. Each git branch of an addon should specify what OF version it is confirmed to work with. This would be parsed and displayed in ofxaddons.com. Developers who confirm that a branch works in a specific OF version can create a PR to update the addon's readme.

2. ofxaddons.com should allow you to sort addons by branches proven to work in OF x.x

3. When creating a project through ProjectGenerator, PG should detect whether the master branch of an addon is compatible with the version of OF linked to. When the master branch is not compatible, it should check whether there is a compatible branch/commit and, if so, offer to clone the addon to the project directory as a local addon. It should also automatically switch to the compatible branch/commit. And when none is confirmed as compatible, it should throw up a warning.

4. Projects could specify compatible addon branches in the addons.make file.

Also related to this issue... it would be worth keeping an eye on this repo by @thomasgeissl : https://github.com/thomasgeissl/ofPackageManager

PackageManager could potentially be designed to automatically create an issue on an addon's github repo when a developer confirms a branch works for a later OF version than stated in the addon branch's readme.

[johndpope]

Cocoapods gets around the version problems using a gemfile / so there's a podfile specifying the library version e.g. aFNetworking version 3.00 and respective versions / then a gemfile that can lock in a specific cocoapods version v1.0beta
By using bundler install you can easily get to older version.

https://guides.cocoapods.org/using/a-gemfile.html