bernd / fpm-cookery

A tool for building software packages with fpm.
Other
460 stars 88 forks source link

Remove dependency installer #122

Closed bernd closed 9 years ago

bernd commented 9 years ago

This feature has always been a bit brittle because some dependency definitions didn't work with Puppet and resultet in errors. There is also a problem with incompatibilities between different Puppet and Ruby versions. Puppet 3.x does not work with Ruby 2.2 and Puppet 4.x only works with Ruby 2.x.

Dependencies can be installed manually in the build method of the recipe or in one of the lifecycle hook methods like before_build by executing the needed apt-get/yum commands via the sh() method. This is more work for the user but is also more flexible.

beddari commented 9 years ago

I was a happy user of this feature :)

Understand why you'd want the simplification but I think it is bad for the recipies to become more (too?) specific rather than abstract. I realize my multi-platform usage is not the norm.

What about e.g https://github.com/mizzy/specinfra/blob/master/lib/specinfra/command/redhat/base/package.rb ...

boc-tothefuture commented 9 years ago

An abstraction for installing dependencies seems like a core feature for FPM-cookery. The shell based approach hurts portability which I see as a key feature of the underlying fpm system. If this PR gets merged, I don't think I would use the hooks for dependencies. I am doing all of my fpm-cookery builds inside of vagrant, which is configured by chef. I would probably just include a dependency recipe to be invoked before starting fpm. However, I don't think that is as optimal as before when all of the build instructions were in a single fpm recipe.

It's too bad the puppet module is brittle in this context.

Is there a middle ground? Could you remove the gem requirement for puppet, freeing fpm-cookery from the ruby/puppet dependency chain? If puppet was installed fpm-cookery can generate a manifest and call puppet apply, If puppet is not installed the user gets an error message saying dependency installation is only available if puppet is installed. That punts the puppet/ruby issue to the user which seems fair.

bernd commented 9 years ago

@beddari I actually use fpm-cookery for multi-platform packages. :wink: (https://github.com/Graylog2/fpm-recipes) Thanks for the feedback on the dependency installer and the specinfra hint.

@brian-oconnell Thanks for your feedback! Interesting that the dependency installation is a core feature for you, this is valuable feedback.

I think a middle ground could be to import the Puppet code that deals with package installation into fpm-cookery. That way we could even try to fix the problems we had in the past because we control the code. This means more maintenance work of course, but I am willing to give this a shot to be able to keep this feature and improve the situation.

What do you think?

boc-tothefuture commented 9 years ago

@bernd It seems like a reasonable approach to me on the surface. But I have not looked at how hard it would be to extricate just the packaging code from Puppet. I also don't know the ramifications of bringing Apache licensed source into a BSD project.

kisoku commented 9 years ago

Oooof. I absolutely depend on automatic dependency installation. Please don't remove it

kisoku commented 9 years ago

Honestly, the only thing I would like to see change here is not merging the build and runtime deps during the install-deps, this really bogs down some of my build times.

glensc commented 9 years ago

as for Puppet vs Ruby version issues, maybe replace Puppet with Chef?

bernd commented 9 years ago

I think I will experiment with a simple custom installer for packages to remove the problematic Puppet dependency. We only need to install packages and not manage them like Chef and Puppet do so it shouldn't be too hard. Until then I will keep the code as it is.

Thanks for all your feedback! Closing this now.