embed gems and install locally about puppet-archive HOT 14 CLOSED

Isn't this the kind of thing that packaging as RPMs solves?

from puppet-archive.

RPMs only work on redhat flavored linux. :(

from puppet-archive.

I've used fpm to build Debian packages as well.

from puppet-archive.

Also using Windows and AIX as well. So thats three platforms I have to build packages for, which is why I just bundled them into the module.

from puppet-archive.

In that case, I'm wondering if that is out of the scope of puppet-archive and should belong in a profile.

@nanliu @daenney

from puppet-archive.

Yeah, so no, I'm not OK with this on so many levels. For one, we'd start embedding gems in our modules which increases the module size. Worse, it puts a burden on the maintainers to ensure that these gems are kept up to date and that this behaviour works reliably across the myriad of environments this module can be used on. That's not even getting into possible security issues that we now need to watch out for for all the gems we're including.

If you can't install software of the internet, then you need to solve that problem by having an actual mirror/repository at your disposal that you can use for that purpose.

from puppet-archive.

I am not surprised by your comments. Seems silly to have to resort to this kind of practice. However, vendoring gems is common practice within the ruby community and actually preferred method for best compatibility which is really no different here. As for the size its adds 86K to the repo. Puppet itself vendors a few gems, and in addition also vendors the entire stack with pe-agent package. All applications written in GO embed copies of the libraries they use to make a single binary. Puppet modules should not be treated any different. Puppet modules should work out of the box without reliance of a gem server. I don't see how security or maintenance would be an issue.

Anyways, just something to think about. Not everyone has root with internet access to rubygems.org.

from puppet-archive.

Puppet modules however are not Ruby gems or "the ruby community". We are the Puppet community and we've almost never resorted to bundling external dependencies this way. The packaging of Puppet itself is entirely different from the packaging of a Puppet module. One does not apply to the other.

Go isn't an apt analogy either as you rebuild the whole thing into a single, all-included, binary which every time you build it automatically fetches the latest versions of your dependencies (unless worked around).

And so we start with just 3 gems, and then it's 5, 7, 10, 36. And well, you know, that JVM, well we need that too so lets add that one too because you shouldn't have to rely on your local mirror or Oracle's download servers to get it. And while we're at it, lets add that Windows 2003 ISO image too because you should be able to set up your PXE server with an image for it without... No.

from puppet-archive.

This is why docker exists. Dependency hell...

from puppet-archive.

Yes. Most places I've seen run a gem-in-a-box, gemirro or similar to distribute internal gems and cache/proxy to upstream Rubygems if this is a concern for them.

from puppet-archive.

This module shouldn't really care how the gems get there and whether or not you have internet access. You could put the package installation into a subclass archive::install and add a $manage_gems parameter to control whether archive::install is even called. Then, you could use your roles and profiles classes to load the gems however you need. Flexibility all around.

Whether this is actually needed remains a question, but it seems like a more graceful way to handle such concerns.

from puppet-archive.

True. You could even make it so that the package declarations have configurable source entries.

from puppet-archive.

I would be OK with making the package source/provider configurable. That seems to be an elegant solution.

from puppet-archive.

I'm removing external gem dependencies in #124, so this should no longer be an issue. Please review those changes and feel free to reopen this ticket if you have any other concerns.

from puppet-archive.