Re: [RubyInstaller] Provide Ruby MSI Package Installer for Puppet Automation

[Jon]

> Would it be possible to create an MSI Package that supports ruby
> installation so we can use it for our Windows Ruby Environment?

Hi Luis,

Why doesn't our .exe installer or .7z archives work for your scenario?

Jon

[Justin Baker]

Windows Server lets you manage MSI packages pretty easily.

There are actually some pretty cool things you can do with MSI packages in a Windows Domain Environment that you can't do with an .exe installer.

That being said, I don't know if that's the reason for this request. 

But the fact that the MSI installer is more of a package instead of an installation script makes it easier to manage in deploy-able scenario.

Just my 2cents,

Justin

[Jon]

> > > Would it be possible to create an MSI Package that supports ruby
> > > installation so we can use it for our Windows Ruby Environment?
> > Hi Luis,
> >
> > Why doesn't our .exe installer or .7z archives work for your scenario?
> >
>
> Windows Server lets you manage MSI packages pretty easily.
> There are actually some pretty cool things you can do with MSI packages in
> a Windows Domain Environment that you can't do with an .exe installer.
>
> That being said, I don't know if that's the reason for this request.
> But the fact that the MSI installer is more of a package instead of an
> installation script makes it easier to manage in deploy-able scenario.

And the puppeteers have a cool convenience for Windows users and MSIs with

http://docs.puppetlabs.com/windows/writing.html#packagepackage

That said, one should be able to write a custom helper using

http://docs.puppetlabs.com/windows/writing.html#execexec
https://github.com/oneclick/rubyinstaller/wiki/FAQ#wiki-silent_install

I bet the Puppet support list has examples of how to handle .exe's and archives. If not, summarize the scenario and ask for their recommended solution. I'm interested in what they recommend.

Jon

[Justin Baker]

Just took a look at the docs you linked, the `msi` provider is deprecated and they suggest you use the `windows` provider instead.

http://docs.puppetlabs.com/references/latest/type.html#package

So it looks like it the installer would be able to be run in an "expected" way.

All that being said, I may look at building an MSI package. It would make some aspects of what I need to do sometimes much easier.

But that's something I won't really be able to do anytime soonish.

Justin

[Jon]

> > > > > Would it be possible to create an MSI Package that supports ruby
> > > > > installation so we can use it for our Windows Ruby Environment?
> > > > Hi Luis,
> > > >
> > > > Why doesn't our .exe installer or .7z archives work for your scenario?
> > > >
> > >
> > > Windows Server lets you manage MSI packages pretty easily.
> > > There are actually some pretty cool things you can do with MSI packages
> > in a Windows Domain Environment that you can't do with an .exe installer.
> > >
> > > That being said, I don't know if that's the reason for this request.
> > > But the fact that the MSI installer is more of a package instead of an
> > > installation script makes it easier to manage in deploy-able scenario.
> >
> >
> > And the puppeteers have a cool convenience for Windows users and MSIs with
> >
> > http://docs.puppetlabs.com/windows/writing.html#packagepackage
> >
> > That said, one should be able to write a custom helper using
> >
> > http://docs.puppetlabs.com/windows/writing.html#execexec
> > https://github.com/oneclick/rubyinstaller/wiki/FAQ#wiki-silent_install
> >
> > I bet the Puppet support list has examples of how to handle .exe's and
> > archives. If not, summarize the scenario and ask for their recommended
> > solution. I'm interested in what they recommend.
> >
>
> Just took a look at the docs you linked, the `msi` provider is deprecated
> and they suggest you use the `windows` provider instead.
>
> http://docs.puppetlabs.com/references/latest/type.html#package
>
> So it looks like it the installer would be able to be run in an "expected"
> way.

:) just saw that too and the `install_options` and `uninstall_options`.

> All that being said, I may look at building an MSI package. It would make
> some aspects of what I need to do sometimes much easier.
> But that's something I won't really be able to do anytime soonish.

The installer originally was an MSI. You can spelunk the git history for details, but I believe the issue was a weakness (file discovery?) with Wix. When I got involved, the installer had already switched from MSI to a rudimentary Inno exe. I haven't looked at Wix in a long time, but with large file count projects like TortoiseHg using it and the recent Wix 3.6 release, I bet things (Heat?) are better.

As you allude, a key issue is bandwidth. Another is whether an MSI is substantially better than our current exe to justify the effort.

Luis:

* We have no current plans to provide an MSI installer.
* Puppet appears to be able to be able to handle our current installers; please double check with them.
* If the Puppet gurus provide a recommendation, please reply to this thread with a link. Thanks.

Jon

---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

[Justin Baker]

On Monday, October 8, 2012 6:58:35 PM UTC-5, Jon wrote:

> All that being said, I may look at building an MSI package. It would make
> some aspects of what I need to do sometimes much easier.
> But that's something I won't really be able to do anytime soonish.

The installer originally was an MSI. You can spelunk the git history for details, but I believe the issue was a weakness (file discovery?) with Wix. When I got involved, the installer had already switched from MSI to a rudimentary Inno exe.  I haven't looked at Wix in a long time, but with large file count projects like TortoiseHg using it and the recent Wix 3.6 release, I bet things (Heat?) are better.

As you allude, a key issue is bandwidth. Another is whether an MSI is substantially better than our current exe to justify the effort.

Actually, it's not as much a bandwidth that's an issue it's package management.

Right now deploying Ruby to certain machine requires a bit of finesse with installation scripts, I ended up just rolling a customized login script.

The problem came when I decided to upgrade Ruby, it wasn't a trivial process. 

With an MSI package I can basically just tell my server to assign the new version of Ruby to these machines, and mark the old version for an uninstall.

 

Luis:

* We have no current plans to provide an MSI installer.
* Puppet appears to be able to be able to handle our current installers; please double check with them.
* If the Puppet gurus provide a recommendation, please reply to this thread with a link. Thanks.

If I do decide to look into an MSI package it would probably be more along the lines of a "package" rather than an installer. 

Since MSI packages can be installed it could function as an installer, but I personally would know exactly what I wanted.

From there I would look into how to build it into the recipes. However, from a personal perspective an MSI package makes sense for me.

I don't see myself running into the scenario I would need to upgrade Ruby or manage the installations anytime soon, but that's the scenario.

I'll also admit I didn't put two and two together until today. It's not an extremely well thought out plan. 

But if we want to look into RubyInstaller being a better citizen in a managed environment this may be something to consider.

Justin

[Jon]

Please open up a new GH feature request issue to better discuss these MSI installer benefits.

MSIs are so shiny and alluring that we leapt past Luis' original MSI-for-Puppet question ;)

Jon

[Josh Cooper]

On Mon, Oct 8, 2012 at 5:56 PM, Justin Baker <azol...@gmail.com> wrote:
> On Monday, October 8, 2012 6:58:35 PM UTC-5, Jon wrote:
>>
>> > All that being said, I may look at building an MSI package. It would
>> > make
>> > some aspects of what I need to do sometimes much easier.
>> > But that's something I won't really be able to do anytime soonish.
>>
>> The installer originally was an MSI. You can spelunk the git history for
>> details, but I believe the issue was a weakness (file discovery?) with Wix.
>> When I got involved, the installer had already switched from MSI to a
>> rudimentary Inno exe. I haven't looked at Wix in a long time, but with
>> large file count projects like TortoiseHg using it and the recent Wix 3.6
>> release, I bet things (Heat?) are better.
>>
>> As you allude, a key issue is bandwidth. Another is whether an MSI is
>> substantially better than our current exe to justify the effort.
>
>
> Actually, it's not as much a bandwidth that's an issue it's package
> management.
>
> Right now deploying Ruby to certain machine requires a bit of finesse with
> installation scripts, I ended up just rolling a customized login script.
> The problem came when I decided to upgrade Ruby, it wasn't a trivial
> process.
>
> With an MSI package I can basically just tell my server to assign the new
> version of Ruby to these machines, and mark the old version for an
> uninstall.

MSI's are a pain to work with, but they excel when it comes time to upgrade.

>>
>> Luis:
>>
>> * We have no current plans to provide an MSI installer.
>> * Puppet appears to be able to be able to handle our current installers;
>> please double check with them.
>> * If the Puppet gurus provide a recommendation, please reply to this
>> thread with a link. Thanks.

Puppet 2.7.x and 3.0 can manage MSI's. Puppet 3.0 can also manage
executable installers (InstallShield, NullSoft, Inno Setup, etc). I
can't find the documentation for it at the moment, but the ticket
we've been using to track it is here:
http://projects.puppetlabs.com/issues/11870

With that said, Puppet itself requires ruby, so we've created an MSI
that includes ruby, gems, puppet, etc. This greatly simplifies the
bootstrapping problem for us. The repo is here:
https://github.com/puppetlabs/puppet_for_the_win. The most interesting
parts are the rake tasks we use to drive the wix toolset:

https://github.com/puppetlabs/puppet_for_the_win/blob/master/tasks/windows/windows.rake

and the main puppet.wxs file, which includes the fragments generated by heat:

https://github.com/puppetlabs/puppet_for_the_win/blob/master/wix/puppet.wxs

> If I do decide to look into an MSI package it would probably be more along
> the lines of a "package" rather than an installer.
>
> Since MSI packages can be installed it could function as an installer, but I
> personally would know exactly what I wanted.
> From there I would look into how to build it into the recipes. However, from
> a personal perspective an MSI package makes sense for me.
>
> I don't see myself running into the scenario I would need to upgrade Ruby or
> manage the installations anytime soon, but that's the scenario.
>
> I'll also admit I didn't put two and two together until today. It's not an
> extremely well thought out plan.
> But if we want to look into RubyInstaller being a better citizen in a
> managed environment this may be something to consider.
>
> Justin
>

> --
> You received this message because you are subscribed to the Google Groups
> "RubyInstaller" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rubyinstaller/-/qFmCLOje_AQJ.
>
> To post to this group, send email to rubyin...@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyinstalle...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyinstaller?hl=en.



--
Josh Cooper
Developer, Puppet Labs

[Octagon]

On Tuesday, October 9, 2012 12:41:48 AM UTC+4, Luis Mayorga wrote:

Hi,

Would it be possible to create an MSI Package that supports ruby installation so we can use it for our Windows Ruby Environment?

Comments?

I am a humble and modestly active Ruby user, but I have some tech support and user management experience and cannot help feeling I am better with red lines than the Ruby Installer team. I would recommend one to be drawn here due to the following reasons.

Any installer for Ruby is a nice to have if easy addition. It is nice to have the current InnoSetup one, but the archive is also sufficient.

Usable Ruby means gems and there can be no guarantee that any installer will handle that properly. Actually Ruby has the installer and it is not MSI but Gem. BTW, if used in a managed environment, an installer must handle all gems. Key words are must and all.

Managed environments tend to control more than a reasonable person may expect. The simplest set of decisions (Put Ruby on Path? Let Ruby open .rb or .rbw files? Allow multiple Rubies? Allow gem installation? .... ) will make an installer suitable for managed environment huge.

Technology does not spread from managed environments outwards. It is pushed down through the throats of managers into managed environments.

My advice: forget about it and let the specialists in managed environments handle the task. You may also want to setup a zero tolerance policy on this kind of requests.

[Jon]

> > With an MSI package I can basically just tell my server to assign the new
> > version of Ruby to these machines, and mark the old version for an
> > uninstall.
>
> MSI's are a pain to work with, but they excel when it comes time to upgrade.

I also like MSIs upgrade capabilities.

But I don't see a real need for powerful upgrade capabilities for RubyInstaller. I believe the focused approach of our Inno exe or 7z archives is a good, non-complex tradeoff as long as (a) manually, they're easy for people to use, and (b) they allow downstream automation experts to add their awesomeness.

I'm wary of creating complexity that creates oddball corner cases or takes away downstream flexibility. I'd rather deliver solid, functional building blocks that people can easily repackage a la Lego blocks.

Can you tell my personal bias is for simple 7z archives? ;)

That said, Justin has a compelling MSI usage scenario. If you have feedback, we'd appreciate your insight at

https://github.com/oneclick/rubyinstaller/issues/136

> >> Luis:
> >>
> >> * We have no current plans to provide an MSI installer.
> >> * Puppet appears to be able to be able to handle our current installers;
> >> please double check with them.
> >> * If the Puppet gurus provide a recommendation, please reply to this
> >> thread with a link. Thanks.
>
> Puppet 2.7.x and 3.0 can manage MSI's. Puppet 3.0 can also manage
> executable installers (InstallShield, NullSoft, Inno Setup, etc). I
> can't find the documentation for it at the moment, but the ticket
> we've been using to track it is here:
> http://projects.puppetlabs.com/issues/11870
>
> With that said, Puppet itself requires ruby, so we've created an MSI
> that includes ruby, gems, puppet, etc. This greatly simplifies the
> bootstrapping problem for us. The repo is here:
> https://github.com/puppetlabs/puppet_for_the_win. The most interesting
> parts are the rake tasks we use to drive the wix toolset:
>
> https://github.com/puppetlabs/puppet_for_the_win/blob/master/tasks/windows/windows.rake
>
> and the main puppet.wxs file, which includes the fragments generated by heat:
>
> https://github.com/puppetlabs/puppet_for_the_win/blob/master/wix/puppet.wxs
>
>

> ...SNIP...

>
> --
> Josh Cooper
> Developer, Puppet Labs

Josh, thank you. This is great info re: Puppet 3.0 and your automation recipes using Wix.

We could really use a simple example linked to https://github.com/oneclick/rubyinstaller/wiki/Tutorials showing how to use this Puppet 3.0 awesomeness with our Inno installer or 7z archive.

I'm curious, given your hard-won experience, what's your priority of the following from an automation perspective? Which do you think are easier for downstream tool providers and users to use?

* simple 7z archives
* exe installers such as Inno
* MSI packages

Thanks again for your feedback and we'd appreciate any thoughts you may have on MSI pros/cons at https://github.com/oneclick/rubyinstaller/issues/136

[Luis Mayorga]

Hi,

We are using puppet as our provisioning engine to all our build agents that support ruby and puppet mostly support msi. I guess i can handle it by using Puppet Exec as you mention further down.

[Jon]

It looks like Josh and the other puppeteers have implemented really cool support in Puppet 3.0 for non-MSI installers.

Take a look at the links Josh provided and see if those work for what you're doing...specifically:

http://docs.puppetlabs.com/references/3.0.0/type.html#package (the `windows` provider, not `msi')
http://projects.puppetlabs.com/issues/11870 (jre 7u5 example)

Regardless of which Puppet version you're using, I'd love to hear specifics on how you eventually solved this issue.

Thanks,