The real Ruby vs. Python.

[Austin Ziegler]

On Wed, 27 Oct 2004 23:11:19 +0900, Abe Vionas_MailingList

I don't have much to disagree with here -- I think that Ruby's support
for Windows leaves quite a bit to be desired, but will note that it's
mostly on things that have historically been troublesome on Windows in
any case (MySQL support, etc.) and that Win32 API support is extremely
strong, although we need more Win32 binary builds of things like
Win32::Event and Win32::Service. The following statement, however, is
(IMO) problematic:

I for one will not even look at a library that hasn't had a release in 2004.

I work on and maintain several libraries. Text::Format hasn't been
changed -- because it does its job well and doesn't need further
changing, yet. MIME::Types has had minor changes to try to make it
more compliant with known lists, but it will see at most two updates a
year (and probably fewer than that when the three features I want to
add are put in: filemagic support, shared-mime support, and reading
existing mimecap files). Just because a program or library is old
doesn't mean that it's out of date. It means that few or no bugs have
been reported against the program or library and no feature requests
have been made to drive development.

Archive::Tar::Minitar -- never intended to be a full tar replacement
-- may see one more feature release and then only periodic releases to
make sure that it's compatible with the current version of Ruby. Why?
Because it simply *works*. It does what it's supposed to do. If it
doesn't work as it is and what it claims to do, then submit a bug!
Don't assume that because it hasn't been updated in 2004 that it's out
of date or unworkable.

-austin

 

[Austin Ziegler]

On Wednesday 27 October 2004 10:48 am, Howard Lewis Ship wrote:
| Cygwin, by explantion, is a POSIX layer on top of Windows. It adds
| aptget/rpm type functionality ... you download a small installer and
| it downloads package descriptions for all the (Li|U)nixy stuff. It
| handles downloading, installing, versioning, dependencies.
|
| http://www.cygwin.com/
Are there downsides to this approach for Windows users?

Yes. IIRC, you lose all Win32 API interaction, especially Win32OLE,
which is an extremely compelling reason to use Ruby on Windows.

-austin

 

[Aredridel]

I can get interested developers a terminal account on windows server
if they need. I know windows boxes are in short supply in a lot of
places .

Ari

 

[Joao Pedrosa]

Hi,

Python on windows has a broad range of libraries
available for anything you could ever dream of:
Apache, Java, Email, Protocols, GTK, Qt, Tk, OpenGL,
PostgreSQL, MySQL, etc etc etc. As far as Python
library availability for Linux, I really don't know,
as I was only looking for windows stuff last night. My
feeling is that while not being quite as comprehensive
as it's windows offerings it still offers a good
depth.

The grass is greener at the neighbor's.

Seriously, Python does seem to have more libs on Windows, or maybe, a
couple of more important libraries (like mod_python?).

I like Ruby-ODBC a lot. With it you could access MySQL, PostgreSQL,
Firebird, etc. It's a very nice library on Linux and on Windows.

As for mod_ruby I think that some people do have it on Windows, but
it's not supported by the community or for the community. Too bad.

ERuby seems to have a compiled version for Windows, but with CGI it's
kind of slow.

FastCGI is a mistery for me, but I wish it was easily available on Windows.

Sometimes we forget that Python has it share of problems as well. Some
Ruby libraries are very well supported or have been created very well
in the first place.

The only issue with Windows that I have is that I wish Ruby had better
threading (native thread?) and I/O did not lock or worked as expected
(see the FreeRIDE debugger issues for example.) Other than that, I'm
relatively happy with the cross-platform opportunity provided by Ruby.

Cheers,
Joao

 

[Michael DeHaan]

Dare I say it, but cloning CPAN near-exactly wouldn't be a bad way to go.

And that means putting RPAN (or whatever) as part of the Ruby standard
library, having college mirrors, doing dependancy checking, and so
forth.

 

[Curt Hibbs]

Dare I say it, but cloning CPAN near-exactly wouldn't be a bad way to go.

And that means putting RPAN (or whatever) as part of the Ruby standard
library, having college mirrors, doing dependancy checking, and so
forth.

This is not quite the same thing, but...

The One-Click Ruby Installer for Windows is going to include RubyGems and a
GUI interface to RubyGems. RubyGems will be in the final 1.8.2 release of
the installer (hopefully the GUI interface will be ready in time to be
included as well). It is also possible that a follow-on release would
contain RPA (and a corresponding GUI interface).

Curt

 

[Curt Hibbs]

This is not quite the same thing, but...

The One-Click Ruby Installer for Windows is going to include
RubyGems and a
GUI interface to RubyGems. RubyGems will be in the final 1.8.2 release of
the installer (hopefully the GUI interface will be ready in time to be
included as well). It is also possible that a follow-on release would
contain RPA (and a corresponding GUI interface).

Oh yeah, and we also working on an installer for OS X that will contain the
same thing. (We still need to find someone to do an installer for KDE and
Gnome).

Curt

 

[trans. (T. Onoma)]

| > Dare I say it, but cloning CPAN near-exactly wouldn't be a bad way to go.
| >
| > And that means putting RPAN (or whatever) as part of the Ruby standard
| > library, having college mirrors, doing dependancy checking, and so
| > forth.
|
| This is not quite the same thing, but...
|
| The One-Click Ruby Installer for Windows is going to include RubyGems and a
| GUI interface to RubyGems. RubyGems will be in the final 1.8.2 release of
| the installer (hopefully the GUI interface will be ready in time to be
| included as well). It is also possible that a follow-on release would
| contain RPA (and a corresponding GUI interface).

And use the same GUI for both?

Seems to me it would be best of Gems team and RPA team really worked hard
together to create shared framework. Gems serving as a general packaging
framework and the idea of RPA becoming QC would be a real boon for Ruby.
--Mind you though, setup.rb still does things they can't. So lets draw that
in too.

Together we stand, divided...

As they say,
T.

 

[dross]

*shrug* RPA isn't trying to mock CPAN exactly. We are trying to implement
a large repository like CPAN, but make te system have nice features, maybe
a -testing repository, etc. A big maybe is a -testing where users do
upload thier own .rps files, but give no promise on the system. Just some
ideas that cooked up from batsman and others in #rpa on freenode networks.

David Ross

 

[dross]

This is not quite the same thing, but...

The One-Click Ruby Installer for Windows is going to include RubyGems and
a
GUI interface to RubyGems. RubyGems will be in the final 1.8.2 release of
the installer (hopefully the GUI interface will be ready in time to be
included as well). It is also possible that a follow-on release would
contain RPA (and a corresponding GUI interface).

Curt

Curt, I will hope that we can maybe release a version with RPA even
sooner. The RPA team and I are very fast hackers. I think I could have
many packages built that would seem awesome(big) in package count and QA
support if anything goes wrong people have a place to nag instead of the
developers.

Dross

 

[Eivind Eklund]

I feel gems is one of the keys to getting past this. Gems can make my
local (Windows) Ruby install feel like
- a single plug-in system
- pulling together 'requires'
- incorporating documentation from a single starting point
- including compatible versions and dependencies

The latter is a property of package repository administration, not of RubyGems.

It would be great if gems was part of the standard Ruby distribution, if RPA
could use gems as its underlying package manager (reducing confusion for
newBs),

This is something we (the RPA team) consider infeasible; RubyGems does
not have the capabilities we believe necessary. This is both in terms
of RubyGems presently being less technically advanced than rpa-base,
and in terms of one key capability: The ability for RPA to modify the
technology to suit our needs.

The key aspect of RPA is providing *maintainenance* for packages, and
not just for the packaging. The idea is that you can take a "blessed"
(core) RPA package, and you'll know:
- That the packaged software itself is of reasonable quality
- Security issues will be fixed
- That as far as is reasonably possible, the code will be fixed for
compatibility with newer versions of other packages
- We'll do bugfixes of packages for newer versions of Ruby
- There is a contact point for all the trivial little patches and
bugfixes that make the difference between a "well worn" package and an
annoying green one. This contact point remains even if the original
author lost interest in the software


This is a large task. The present rpa-base and package set only
scratch the surface of what we're trying to do. We're presently
looking at the next step in the enabling this:

- A new version of rpa-base that support the development cycle for the
above much better (integration with version control system to make
maintenance of code uniform etc)
- Documentation to help more people be able to do RPA packaging
- Documentation and checklists for helping software quality
- Building a review team for doing code review for code we import into the RPA
- Support for binary packages, to make Ruby deployment on Windows etc easier
- Increase in team size

As this stuff gets done, we'll have more to do, of course.

and if RPA could then also take on the role of Release Manager for
Ruby itself.

We may be willing to do this, but

Some misc thoughts:

- Could gems ALSO cover binaries AND binary/library dependencies?

RPA is working towards this.

- Could the gems RDOCs have links to some gems-aligned community
documentation site, as someone else proposed here recently?

It is not clear to me what you want here. Cross-links between
packages is certainly interesting for RPA, at least.

Eivind.

 

[Eivind Eklund]

We may be willing to do this, but

... oops - lost the end of this - "but we presently do not have the
resources where I think we could do this well."

Continuing with a comment from T.Onoma:

Seems to me it would be best of Gems team and RPA team really worked
hard together to create shared framework. Gems serving as a general
packagingframework and the idea of RPA becoming QC would be a real
boon for Ruby.

As I've said elsewhere: The problem is that the goals of RPA is
already quite ambitious, and that we feel we need to "own" the
packaging infrastructure for our packages. There are several of the
things we do right now that requires us to hack that infrastructure.

Doing RPA without controlling the packaging infrastructure is
something that I think would result in quite a lot worse result. A
result so much worse that you'd lose the motivation that drives the
RPA team. And then we'd be back at square one.

Eivind.

 

[David Ross]

| > Dare I say it, but cloning CPAN near-exactly wouldn't be a bad way to go.
| >
| > And that means putting RPAN (or whatever) as part of the Ruby standard
| > library, having college mirrors, doing dependancy checking, and so
| > forth.
|
| This is not quite the same thing, but...
|
| The One-Click Ruby Installer for Windows is going to include RubyGems and a
| GUI interface to RubyGems. RubyGems will be in the final 1.8.2 release of
| the installer (hopefully the GUI interface will be ready in time to be
| included as well). It is also possible that a follow-on release would
| contain RPA (and a corresponding GUI interface).

And use the same GUI for both?

Seems to me it would be best of Gems team and RPA team really worked hard
together to create shared framework. Gems serving as a general packaging
framework and the idea of RPA becoming QC would be a real boon for Ruby.
--Mind you though, setup.rb still does things they can't. So lets draw that
in too.

Together we stand, divided...

As they say,
T.

This would not work. I'm creating a GUI for Windows, I have more
experience with GUI design and what a user wants in a easy to use gui.
If you want the job done right, you've got ot do it yourself. I will
make sure my GUI for RPA(on windows currently) is feasible where maybe
others could use it as well. I will keep others in mind. However I
dislike the way people design, and so I have to do it myself. Its a
perfection task, not a personal one. I like easy-to-use- guis with good
design.

My implementation of the RPA GUI is to use WideStudio first because its
much easier than any other, then I will port it to a popular(aka native
- really its not, its called popular; Qt, GTK, etc) toolkit using GUI
toolkit. WideStudio has its own widgets, and I'm aware not everyone
likes a non-popular toolkit look. So I'll rewrite it quickly in another.
It will also be for Unix OSes depending if I see it good or not.
Possiblyeven porting it to unix, depending how I will implement it to
jump to root.

David Ross

 

[Daniel Berger]

What it comes down to is what it's coming down to for
me... platform maturity.

Python on windows has a broad range of libraries
available for anything you could ever dream of:
Apache, Java, Email, Protocols, GTK, Qt, Tk, OpenGL,
PostgreSQL, MySQL, etc etc etc.

Ruby has these, too.

Ruby, on the other hand, while it has a comprehensive
offering on the Linux platform, is hamstrung on
windows by it's lack in important areas.

Such as?

If libraries
exist, they more often then not are NOT being actively
maintained (my research last night indicated that by
and large more Python libraries are continually
actively maintained).

Again, you don't state specifically which libraries.

This last point is important
because at one time or another Ruby has HAD libraries
to cover any need, but without active maintenance they
are nearly worthless. I for one will not even look at
a library that hasn't had a release in 2004.

Still no info.

So, this is what it comes down to for me... Which
language offers what I need in terms of libraries? I
decided to go looking after having an excrutiating
time finding just Ruby FastCGI, mod_ruby, and
PostgreSQL libraries which would actually work on
Windows - forget being maintained at all. No luck
though. Even a post to the Ruby-Talk list asking for
help with an attempt to install FastCGI for Ruby
yielded only one reply.

Ok, so we've come to the crux of your post - you had problems with
PostgreSQL and FastCGI. So, from that you've drawn the conclusion
that Python has superior library support on Windows?

Finally, while the Ruby Gem system is exceptionally
easy to work with and a real boon to Ruby, it doesn't
quite match the ease of installing ANY given Python
library. Every Python windows library for the most
part comes with a windows installer (exe or msi).

You can thank Mark Hammond for the libraries, and Sophos (aka
ActiveState) for the packaging. Ruby doesn't have a company backing
it (yet).

Keep in mind that it may be more doable to run Ruby on
windows given substantial C programming/compiling
experience, I don't know. Obviously, if I had the
experience to satisfy that statement I would be able
to answer my own question. : -)

Between ruby/dl, WIN32API and OLE + WMI you can do just about anything
you need without a C compiler.

So, for those of us who aren't C gurus and don't run
Linux, Python seems to win out when compared to Ruby.

WHAT SPECIFICALLY ARE YOU MISSING?

Which is unfortunate because I really love Ruby, and
don't like a number of Python elements. However,
having the capabilities I need is much more important
than syntax preferences at the moment.

Sadly, in order for Ruby to really take over the world
it will require a more substantial focus on providing
windows compatible libraries and maintaining those
libraries.

Start with http://www.rubyforge.org/projects/win32utils. There's a
Windows installer, too, so you don't have to compile anything
yourself.

If Ruby continues to be a Linux-centric
language... I don't know. It just seems to me fairly
obvious that in order to have true dominance you have
to meet the needs of the major platforms. Python does
this moreso then Ruby. And believe me, I wish it were
the other way around.

Without any specific examples, this is nothing but hand waving.

I'll keep my eye on Ruby, and return when it offers
the essentials I require.

Which we have narrowed down to Postgres and FastCGI.

But until then I'll be
laboring under a hot Python sun.

You're laboring under worse than that I fear.

- Dan

 

[gabriele renzi]

David Ross ha scritto:

You can use mingw32. Help out you blasted lypanov. I told earlier you
its up to us, not end users.

actually you can use MS' stuff as it is available free as in beer
(compiler and nmake, at least)

 

[David Ross]

David Ross ha scritto:


actually you can use MS' stuff as it is available free as in beer
(compiler and nmake, at least)

I'm aware, but I usually compile win32 program on my bsd machine with
the mingw port. I can install the microsoft compiler later maybe.
Thanks though.

David Ross

 

[gabriele renzi]

Justin Rudd ha scritto:

I've tried a bit. I've got MySQL, PostgreSQL, and SQLite/Ruby
compiled for Windows. The PostgreSQL I haven't released because I
haven't tested it thoroughly. Although I'll probably release the
PostgreSQL one and let the community test it for me

My next project is OpenSSL so that I can use the Ruby SSH project.
But that is going to be awhile (I'm in the middle of moving from
Arizona to Washington).

this may help:
http://www.garbagecollect.jp/ruby/mswin32/en/

the win32 binary contains every ruby extension library that is included
with the interpreter, and openssl.so /seemed/ to work with openssl from
openssl.org. Sadly this page is often forgotten

The thing I've noticed is that the extension library code (the C code)
usually has dependencies on things that are not defined in Windows.
That is what takes the most time to get around. But the good news is
that it is a small minority of projects that have this problem.

that's why people should use ruby/dl, say 'boo' for c bindings

 

[gabriele renzi]

trans. (T. Onoma) ha scritto:

Seems to me it would be best of Gems team and RPA team really worked hard
together to create shared framework. Gems serving as a general packaging
framework and the idea of RPA becoming QC would be a real boon for Ruby.
--Mind you though, setup.rb still does things they can't. So lets draw that
in too.

Together we stand, divided...

there are philosophical and practical differences in approaching
packaging that makes this impossible, for what I understand. But the
teams collaborate and share stuff. So it is a "We stand togheter, even
if we don't hug"

 

[Jamis Buck]

that's why people should use ruby/dl, say 'boo' for c bindings

True. However, Ruby/DL has a compile-time limit (defaults to 10) on the
number of callbacks you can use, which limits its usefulness in
situations where callbacks are needed. This includes the Win32 API (for
winprocs), or SQLite (where callbacks are one way to obtain query results).

Besides which: Ruby/DL is often touted as a great way to write extension
libraries. Are there any examples of libraries that have been written
using Ruby/DL instead of C? I've never seen any, much to my own
frustration when I would like a good example of Ruby/DL usage.

- Jamis

 

[Mauricio Fernández]

I am sure there are things you need beyond core Gems. But there is such a
core of rubygems (at least notionally; I don't know the architecture) that
directly overlaps a core of RPA: installing a package, knowing dependencies,
and installing dependees.

RubyGems installs packages in separate directories; it supports multiple
versions of a lib at a time but it is not totally transparent (you need
a combination of the "require hack" plus executable stubs, and the
datadir issue is yet to be addressed).
rpa-base installs atomically into $prefix; the operations are transacted
and it is transparent; it can track reverse dependencies and GC packages
on uninstall. It can also do parallel installs and update itself.

Even the basics are quite different. The basic, fundamental operation
(installing a package) is arguably stronger in rpa-base because it
is atomic. This is an absolute must because rpa-base manages files
in $prefix.

There is no gain in throwing away a codebase that works well and
replacing it with another that does NOT do what RPA needs, the way it
needs it.

However, we have tried to share code when possible, and it is in that
spirit that we contributed rpa-base's package format code to RubyGems,
which was integrated as of 0.8.0.

module Gem; require_gem 'Core'... end
module RPS; require_gem 'Core' ... end

The deep differences even in the core operations make this approach
impossible.

These are great, and 100% valid. It's just that there is a core that seems
identical, Imho.

Well, it just isn't... Note that the development of rpa-base
began in February; by the time RubyGems 0.2.0 (first public
release) was out, in 2004-03-14, rpa-base was already doing atomic
installations/upgrades/deletions, handling extensions, RDoc generation,
automated unit test runs, etc. I just mention that to illustrate that
the development of these two codebases happened in parallel, and that
different design and implementation choices were taken on each.