Rubyinstaller devel - Aug 2004 - RE: FXRuby and the (new) Ruby Installer for OS X

Lyle Johnson wrote:
>
> On Aug 13, 2004, at 11:08 AM, Curt Hibbs wrote:
>
> > Anyway, I want to include FXRuby, if possible. Do you have (or can
> > have) a
> > binary build of FXRuby for OS X? We could build from source I suppose,
> > but
> > I''m trying to minimize the work Stephen has to do for OS X
installer.
> > So, if
> > you have (or could have) OS X binaries, please let me know.
>
> I do have binaries that I''ve built on my PowerBook, but
I''m a little
> concerned about how we manage dependencies and such. For example, my
> build of FXRuby depends on (at least) the following variables
> particular to my system:
>
> * Mac OS 10.3.4
> * Fink installations of libpng, libjpeg, etc.
> * Apple''s X11 libraries
> * Ruby 1.8.1
>
> ... maybe you get the idea. ;)
>
> I''m happy to provide what I''ve got, we just need to
consider how to
> make sure that it''s going to work well on an arbitrary Mac OS X
> installation. It''s even going to be more of a challenge if you go
to a
> Ruby installer for Linux, I suspect.
I''d like to make it as simple and foolproof for the end-user as
possible,
but I suppose that if it is too problematic, FXRuby can be included as a
checkbox option, and if the user selects it, then the runtime prerequisites
can be clearly displayed (making it the users responsibility). But, if at
all possible, I would prefer to avoid that.
> I wonder if an alternative approach might be to leverage one of the
> existing packaging projects (like Fink, or DarwinPorts) -- try to
> ensure that packages are available for all of the Ruby extensions
we''re
> interested in providing, something like that? Just a thought.
Perhaps, what do you think Steve?

Curt

> I''d like to make it as simple and foolproof for the end-user as 
> possible,
> but I suppose that if it is too problematic, FXRuby can be included as 
> a
> checkbox option, and if the user selects it, then the runtime 
> prerequisites
> can be clearly displayed (making it the users responsibility). But, if 
> at
> all possible, I would prefer to avoid that.
>
>> I wonder if an alternative approach might be to leverage one of the
>> existing packaging projects (like Fink, or DarwinPorts) -- try to
>> ensure that packages are available for all of the Ruby extensions 
>> we''re
>> interested in providing, something like that? Just a thought.
>
> Perhaps, what do you think Steve?
As long as all of the tools we''re installing are already compilable on 
OS X, I''d rather build them on the user''s machine.  That way
they''re
sure that everything matches.  The developer tools are free and I''d 
rather see them install that than dealing with fink or anything else.

Steve

Stephen Steiner wrote:
>
> > I''d like to make it as simple and foolproof for the end-user
as
> > possible,
> > but I suppose that if it is too problematic, FXRuby can be included as
> > a
> > checkbox option, and if the user selects it, then the runtime
> > prerequisites
> > can be clearly displayed (making it the users responsibility). But, if
> > at
> > all possible, I would prefer to avoid that.
> >
> >> I wonder if an alternative approach might be to leverage one of
the
> >> existing packaging projects (like Fink, or DarwinPorts) -- try to
> >> ensure that packages are available for all of the Ruby extensions
> >> we''re
> >> interested in providing, something like that? Just a thought.
> >
> > Perhaps, what do you think Steve?
>
> As long as all of the tools we''re installing are already
compilable on
> OS X, I''d rather build them on the user''s machine.  That
way they''re
> sure that everything matches.  The developer tools are free and
I''d
> rather see them install that than dealing with fink or anything else.
My first choice would be for the user not to have to deal with anything
other than our installer. But if that is not possible/practical, then
here''s
my list of preferences (in descending order):

1) First choice is to be for the installer to be completely self-contained
and not to require anything else to already be installed on his system.

2) Second choice is to partition the stuff to be installed into two groups.
The first group is everything that fits the criteria in #1 above, and the
second group contains the things that require other software to be installed
on the user''s system (compilers, libs, etc.). In this case, everything
in
the second group should be optional and *not* selected by default.

3) The third choice would be that we require a particular set of software to
be installed on the user''s system before our installer can be run.  It
would
be hard for me to believe that this would be necessary, and in my mind, this
option is completely unacceptable.

Curt

> My first choice would be for the user not to have to deal with anything
> other than our installer. But if that is not possible/practical, then 
> here''s
> my list of preferences (in descending order):
>
> 1) First choice is to be for the installer to be completely 
> self-contained
> and not to require anything else to already be installed on his system.
So, basically, ship a bin only distribution?

I was thinking of distributing everything with source code and, if 
that''s the case,
all they would have to install is the free developer tools that came 
with their system.

Then we leverage those tools to build everything else.

I''d be pretty surprised if there are too many people running OS X and 
using
(or wanting to use) Ruby that don''t have the developer tools already 
installed.

I suppose we could just go look for the developer tools and ask, if 
they have them,
how they want to proceed.

Personally, I would much rather build from source for the user''s 
particular setup
than risk potential version mismatches with a pre-built binary.

Steve

Stephen Steiner wrote:
>
> > My first choice would be for the user not to have to deal with
anything
> > other than our installer. But if that is not possible/practical, then
> > here''s
> > my list of preferences (in descending order):
> >
> > 1) First choice is to be for the installer to be completely
> > self-contained
> > and not to require anything else to already be installed on his
system.
>
> So, basically, ship a bin only distribution?
>
> I was thinking of distributing everything with source code and, if
> that''s the case,
> all they would have to install is the free developer tools that came
> with their system.
>
> Then we leverage those tools to build everything else.
>
> I''d be pretty surprised if there are too many people running OS X
and
> using
> (or wanting to use) Ruby that don''t have the developer tools
already
> installed.
>
> I suppose we could just go look for the developer tools and ask, if
> they have them,
> how they want to proceed.
>
> Personally, I would much rather build from source for the user''s
> particular setup
> than risk potential version mismatches with a pre-built binary.
In general, installing binaries is faster and less imposing on the user, and
thus has a better out-of-the-box experience for the end-user. If shipping
binaries is too problematic then I guess we''d have to build from
source.

But, I just can''t imagine that installing a commercial app OS X would
need
to have development tools present to compile source code. How do commercial
products for OS X handle this problem?

I suppose a hybrid approach is also possible. A VMWare installation on
Linux, for example, contains precompiled binaries for the most common target
configuration but falls back to building from source when needed. The main
problem here is handling build failures in a user friendly manner.

I have to rely on your technical expertise as I am speaking from general
knowledge and I am totally ignorant of the technical problems of installing
software on OS X.

Curt

PS
   Your emails don''t seem to be making it to the RubyInstaller-Devel ML
(even though I can see you are sending them there). Are you getting any
rejection or bounce messages back from mailman?

> But, I just can''t imagine that installing a commercial app OS X
would
> need
> to have development tools present to compile source code. How do 
> commercial
> products for OS X handle this problem?
Commercial apps are not programming languages.  A commercial app, if 
done
properly for OS X, is a self contained bundle that can just be dragged 
to the
Applications folder.  When  things have to be installed all over 
creation (/usr/local/lib,
/usr/local/bin etc.) things are more complicated.
> I suppose a hybrid approach is also possible. A VMWare installation on
> Linux, for example, contains precompiled binaries for the most common 
> target
> configuration but falls back to building from source when needed. The 
> main
> problem here is handling build failures in a user friendly manner.
Yes, build failures are definitely a problem.  The .pkg installer has 
pre and post
flight scripts but that''s about it for error handling.  Perhaps one of 
the other
installers does more but I''m not familiar with any of them at this 
point.
> I have to rely on your technical expertise as I am speaking from 
> general
> knowledge and I am totally ignorant of the technical problems of 
> installing
> software on OS X.
OS X == BSD == Linux == Unix, for all intents and purposes when you''re
talking about installing things like Ruby itself.  That''s why I favor a
source
build: you never know exactly what''s there on the system unless you
compile with it.
>    Your emails don''t seem to be making it to the
RubyInstaller-Devel ML
> (even though I can see you are sending them there). Are you getting any
> rejection or bounce messages back from mailman?
>
Nope, they just don''t seem to be making it there for some reason.

Steve

Steve, I''m CC''ing Rich Kilmer on this because he''s a
highly proficient OS X
Ruby developer that may be able to provide some useful feedback (and I
don''t
think he''s on the RubyInstaller-Devel ML)...

The key idea behind the One-Click Ruby Installer is to have a very low
barrier-to-entry for the non-hardcore user, and that this is realized
through a very fast and extremely easy installation. Harcore techies are not
the target audience (they know how to build things from source, and usually
prefer to do their own builds anyway). Our target audience is the much
broader, but less technical user who may not want (or even know about) the
C-based developer toolchain.

On windows the one-click installer is an 11MB download and installs in about
1 minute. If someone wants to try out Ruby on windows, its a no-brainer:
simple and fast to install (just as easy to uninstall). The end-result is a
ready-to-use environment.

If the windows one-click installer required the to first register for a
developer toolset, perform a hundred megabyte download, install the
developer tools, and then run the one-click installer... we would lose our
target audience because most of them would give up and our goal of extending
Ruby to "the masses" would go unrealized.

The hardest of the hard-core Ruby geeks on Windows do their own builds of
Ruby, but a great many professional level Ruby developer''s still use
the
one-click installer for windows. There have been over 12,000 downloads of
the windows one-click installer from RubyForge. And that''s just in the
last
six months! Before that the one-click installer was on SourgeForge and I
don''t have figures for that. This is solid evidence that we are
reaching a
previously unmet need.

Think of our target OS X audience, not as the *nix type geek who is schooled
in the use of C, but rather as the legion of AppleScript users who need
something better (as with windows, hardcore geeks will always roll their
own, but most developers will still prefer a simple one-click installer). We
want to be more like an application, and less like a typical programming
language installation.

We don''t want to be just another packaging system. Correct me if
I''m wrong,
but a source-based installation is already provided by fink and darwinports.
Duplicating this probably wouldn''t sway their hardcore users, and
wouldn''t
be simple enough to reach our target audience.

A good example/model of this type of binary distribution on OS X might be
TclTk Aqua (http://tcltkaqua.sourceforge.net/).

I think the real questions we should be asking are:

1) What are the roadblocks and/or problems with a binary OS X installer?

2) Do these problems have reasonable solutions that we can live with?

If the answer to #2 is "no", then I guess we would have no choice but
to go
with a source-based installer.

Curt

PS
   We should probably add RubyCocoa to the list of included extensions.


> -----Original Message-----
> From: Stephen Steiner [mailto:ssteiner@mac.com]
> Sent: Monday, August 16, 2004 6:57 AM
> To: Curt Hibbs
> Cc: RubyInstaller-Devel
> Subject: Re: FXRuby and the (new) Ruby Installer for OS X
>
>
> > But, I just can''t imagine that installing a commercial app OS
X would
> > need
> > to have development tools present to compile source code. How do
> > commercial
> > products for OS X handle this problem?
>
> Commercial apps are not programming languages.  A commercial app, if
> done
> properly for OS X, is a self contained bundle that can just be dragged
> to the
> Applications folder.  When  things have to be installed all over
> creation (/usr/local/lib,
> /usr/local/bin etc.) things are more complicated.
>
> > I suppose a hybrid approach is also possible. A VMWare installation on
> > Linux, for example, contains precompiled binaries for the most common
> > target
> > configuration but falls back to building from source when needed. The
> > main
> > problem here is handling build failures in a user friendly manner.
>
> Yes, build failures are definitely a problem.  The .pkg installer has
> pre and post
> flight scripts but that''s about it for error handling.  Perhaps
one of
> the other
> installers does more but I''m not familiar with any of them at this
> point.
>
> > I have to rely on your technical expertise as I am speaking from
> > general
> > knowledge and I am totally ignorant of the technical problems of
> > installing
> > software on OS X.
>
> OS X == BSD == Linux == Unix, for all intents and purposes when
you''re
> talking about installing things like Ruby itself.  That''s why I
favor a
> source
> build: you never know exactly what''s there on the system unless
you
> compile with it.
>
> >    Your emails don''t seem to be making it to the
RubyInstaller-Devel ML
> > (even though I can see you are sending them there). Are you getting
any
> > rejection or bounce messages back from mailman?
> >
> Nope, they just don''t seem to be making it there for some reason.
>
> Steve
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004
>

> We don''t want to be just another packaging system. Correct me if
I''m
> wrong,
> but a source-based installation is already provided by fink and 
> darwinports.
> Duplicating this probably wouldn''t sway their hardcore users, and 
> wouldn''t
> be simple enough to reach our target audience.
They offer kind of one-click-ish install but you have to use their 
tools.  They
do a pretty good job with dependencies, though and I may actually use
one or the other to get binaries to be packaged.
> A good example/model of this type of binary distribution on OS X might 
> be
> TclTk Aqua (http://tcltkaqua.sourceforge.net/).
Downloading...  Yes, it is one big package with 50 separate packages, 
one for
each of the included apps.  Very time consuming to build, no doubt.  I 
think I
have come up with a better way.  I''ll let you know when I''ve
proved it
out.
Unfortunately I''m going to have to write some stuff (in Ruby, of 
course) to get
my approach to work since I can''t find a tool that does what I want.
> 1) What are the roadblocks and/or problems with a binary OS X 
> installer?
1> Ruby''s already installed on the system.
2> Things compiled on one version of OS X might have problems running on
      other versions. (this is true of any *nix)
> 2) Do these problems have reasonable solutions that we can live with?
1> 	Not a big deal since ruby is pretty self contained.  Only issue is 
making sure
	that the user''s running the install they think they''re
running.

2> 	This is really the only potential hangup.  I''m running OS X
10.3.5
and, if I were to
	configure/make on my system, there''s a chance that the result
wouldn''t
	run on an earlier version.

	I can make images for a couple of OS X versions but things quickly 
escalate and,
	due to the the sheer number of possible permutations, quickly becomes
	unmanageable.

	Also, testing each installation/OS Version is time consuming.

	I''m probably being overly paranoid here but I really wouldn''t
like to
give users a
	bad impression of Ruby by having an incompatibility between OS X 
versions
	look like a Ruby problem.

	I''ve noticed that many of the binary distributions 	have specific 
downloads for specific
	OS X versions (Tcl/Tk Aqua has separate versions for 10.1, 10.2, and 
10.3 to use
	your example).

I would like to clear up a misperception: OS X ships with the developer 
tools.  There is
no need to download the developer tools unless the version of OS X is 
so old (10.1 from
the beginning of 2001) that Ruby itself won''t build properly with the 
included tools.
>    We should probably add RubyCocoa to the list of included extensions.
Ok!  RubyCocoa, BTW, will be darn close to useless without the 
developer tools.

I have come up with a pretty good way to do the installler package and 
I''m researching
fink and DarwinPorts to see if any of their tools might be helpful.

I''d love to find a good IDE that worked on OS X for Ruby development 
with a built-in
debugger...

I''m going to put together a preliminary doc on what will be installed, 
etc. later today,
mostly to clarify my own thinking on exactly where this project is 
going.

I''ll be very interested to hear RIch''s thoughts on this.

Steve

I have to dash off to a meeting, so I''ll read the rest of your email
more
closely when I get back, but I wanted to respond to the one point below:

Stephen Steiner write:
>
> I''d love to find a good IDE that worked on OS X for Ruby
development
> with a built-in
> debugger...
The choice here would be FreeRIDE. I''ve been holding off including it
in the
windows version because I''m one of the founders of the FreeRIDE project
(Rich Kilmer is the other founder), and I was trying to avoid any
appearances of favoritism.

But FreeRIDE would definitely do the trick here. Its written in Ruby, uses
FXRuby to render its GUI, has a built-in debugger, and offers a parsed
source-tree for navigation (i.e., you can navigate a source file by
module/class/method).
> I''m going to put together a preliminary doc on what will be
installed,
> etc. later today,
> mostly to clarify my own thinking on exactly where this project is
> going.
Excellent!

Thanks again for taking this on,
Curt

On Mon, 2004-08-16 at 13:08, Curt Hibbs wrote:
> The choice here would be FreeRIDE. I''ve been holding off including
it in the
> windows version because I''m one of the founders of the FreeRIDE
project
> (Rich Kilmer is the other founder), and I was trying to avoid any
> appearances of favoritism.
Oh, to hell with favoritism.

I think you should definitely include FreeRIDE in upcoming versions. 
Feel free to blame me for the request :-)

/\ndy

-- 
  Andy Hunt, The Pragmatic Bookshelf
             Practical Books for Pragmatic Programmers
  Toll-free: 800-699-7764                  direct: 919-847-3884
  web: http://www.PragmaticBookshelf.com   email: andy@PragmaticBookshelf.com

Andrew Hunt wrote:
> 
> On Mon, 2004-08-16 at 13:08, Curt Hibbs wrote:
> 
> > The choice here would be FreeRIDE. I''ve been holding off 
> including it in the
> > windows version because I''m one of the founders of the
FreeRIDE project
> > (Rich Kilmer is the other founder), and I was trying to avoid any
> > appearances of favoritism.
> 
> Oh, to hell with favoritism.
> 
> I think you should definitely include FreeRIDE in upcoming versions. 
> Feel free to blame me for the request :-)
Yes, sir! Marching orders noted.. preparing to execute...  :-)

Curt

On Mon, 2004-08-16 at 13:17, Curt Hibbs wrote:
>  
> > I think you should definitely include FreeRIDE in upcoming versions. 
> > Feel free to blame me for the request :-)
> 
> Yes, sir! Marching orders noted.. preparing to execute...  :-)
You guys rock, have I mentioned that lately?

Of course, I''m not so sure about that "preparing to execute"
bit, sounds
a bit like the line where "we couldn''t find the artist, so we had
to
hang the picture" :-)

/\ndy

-- 
  Andy Hunt, The Pragmatic Bookshelf
             Practical Books for Pragmatic Programmers
  Toll-free: 800-699-7764                  direct: 919-847-3884
  web: http://www.PragmaticBookshelf.com   email: andy@PragmaticBookshelf.com

Just testing to see whether I can post directly to the list now...

Steve