wishlist

A prioritized wishlist of refactorings/changes to try and make fpm-cookery fitter, happier & more productive. I'll work (veeery slowly) on these myself but I'm just learning Ruby so it will take time - or not even happen at all. Free to grab this and run! (Jan Ivar Beddari, @beddari)

Rework concepts around omnibus

fpm-cookery has immense potential for becoming the tool to create omnibus-style packages. For that to happen I think some changes are needed.

• Omnibus shouldn't require a separate recipe for the omnibus package. It should be a build-time decision to make a regular or omnibus package - and a feature of the definition to support it or not. This idea needs to be tried out in practice - with a set of Java, Python, Ruby definitions to cover the most common cases.
• Components of the omnibus should optionally (or always ...?) be a full top-level project, a directory. Right now you need to keep all your components inside your project which isn't very DRY. This would also enable linking in git submodules
• Omnibus deps list should be possible to specify on the command line. It would need to cater for order in some way ... maybe just ignore everyting in the definition if it is specified on the command line.
• Omnibus packages (or all packages?) should by default be given filename that reflects the platform and arch it was built on, like demoproject-1.4.0-1.el6.x86_64.rpm or demoproject-1.4.0-1.mac_os_x.x86_64.rpm

I'm about to make an example definition tree showcasing these concepts, will link it here when it is finished.

Make it possible/document how to extend a recipe

It would be nice to be able to extend a recipe to override some attributes with your local values or even provide your own method. I'm not sure what is needed to do this, I tried a while ago but failed due to lack of Ruby foo :-)

Support HEAD and devel like Homebrew

When running fpm-cookery in CI I have two distinct needs. First, I need to be able to consistently build whatever version I currently manage for my infrastructure (stable). Everyting needed for this should be downloaded once, then built as many times I need with as little as possible external depenencies (like downloads ...) from that point.

The second need is to build whatever is the next version, or the "latest version" (devel). This is to be able to keep track of moving components and automatically test newer releases than the current managed one.

This is possible in Homebrew, here is a list of Formulae using both "head" and "devel" and a wiki entry explaining the feature

Provide some form of a Vagrant-based 'build lab'

For easing builds across systems and getting users up and running quicker this would be nice. There is already a lot of code available that does similar things, the best would probably be to use code from omnibus-ruby https://github.com/opscode/omnibus-ruby/blob/master/lib/omnibus/templates/Vagrantfile.erb. That is Apache licensed, don't know if it is compatible.

Update: Very early work on this over at https://github.com/norcams/fpm-refinery

Set up a real CI env, build and publish binaries

This would really get attention to the project. I'd be able to set it up once I've familiarized myself a bit more with bintray - it is looking ideal for this as it can handle uploads via API and exposes uploaded packages as apt/yum repos