[ANN] Tattle - The Ruby Census

[Philip Hallstrom]

Might be nice if the default at list listed them for a second before
continuing. I know some of the FreeBSD ports will spit out a message
saying "you can optionally set such and such to build such and such, press
ctrl-c now" and gives you about 5 seconds before it keeps on going.

That way at least you'd see the optional dependencies and could bail out
if you decide you want them, but not be annoyed (too much) if you don't.

 

[Nathaniel Talbott]

Default: no prompt, no install
-Y: no prompt, install
--optional-dependencies: prompt

A way to install the optional dependencies for an already-installed
gem would be great, too. I'm not thinking of a great syntax off the
top of my head, though.

 

[Philip Hallstrom]

Default: no prompt, no install

A way to install the optional dependencies for an already-installed
gem would be great, too. I'm not thinking of a great syntax off the
top of my head, though.

--only-dependencies

?

 

[Daniel Finnie]

Or maybe --add-optional-dependencies.

It's kind of verbose. -add-all-dependencies is shorter and might also
work...

 

[Chris Carter]

I am now thinking:
-Y: unconditional install of dev deps (like -y, but only for developer deps)
-O: prompted install of dev deps

 

[Gregory Brown]

A way to install the optional dependencies for an already-installed
gem would be great, too. I'm not thinking of a great syntax off the
top of my head, though.

does this need an option?

wouldn't gem install ruport -v 0.6.0 -Y do the trick?

 

[Paulus Esterhazy]

So if I were to spend this weekend getting optional/developer-time
dependencies into RubyGems, would people want optional dependencies to
always be prompted, only prompted when a flag is given, or never
prompted?

I suggest looking at Debian's way of doing it. They have "recommends"
and "suggests" dependencies. (after all, apt is probably the mother of
dependency management systems, and gem is intellectually based on apt-get)

The "aptitude" utility thus has "--with-suggests" and
"--with-recommends", as well as "--without-...".

http://people.debian.org/~dburrows/aptitude-doc/en/rn01re01.html

Of course, debian also has "build-dependencies" which aren't installed
with "apt-get install", but "apt-get build-dep". So a fusion of these
two concepts should do the trick.

FWIW, I'd much appreciate adding such a notion to gem.

Paulus

 

[M. Edward (Ed) Borasky]

I suggest looking at Debian's way of doing it. They have "recommends"
and "suggests" dependencies. (after all, apt is probably the mother of
dependency management systems, and gem is intellectually based on apt-get)

The "aptitude" utility thus has "--with-suggests" and
"--with-recommends", as well as "--without-...".

http://people.debian.org/~dburrows/aptitude-doc/en/rn01re01.html

Of course, debian also has "build-dependencies" which aren't installed
with "apt-get install", but "apt-get build-dep". So a fusion of these
two concepts should do the trick.

FWIW, I'd much appreciate adding such a notion to gem.

Paulus

Which brings up a very interesting question/comment/pet peeve of mine.
Every Linux distro has a package management system, but there really is
no "universal" one. Debian has "apt", Red Hat and quite a few others
have something based on RPM, Gentoo has Portage, etc. OK ... that's
fine, maybe. Now the languages: Perl has CPAN and tools to make use of
it, plus ActiveState has their own Perl Package Manager and
repositories. Ruby has RubyGems, R has CRAN and its own package
management system. I don't do much with PHP, Python or Tcl, but I know
they have their own way of doing things, and that in the case ot Tcl/Tk
and Python, there's also an ActiveState way. That's decidedly *not* fine
-- I spent two days at my day job recently wrestling with just the CPAN,
Cygwin and ActiveState differences and that's just Perl! Nobody is going
to take me seriously if I suggest that Ruby is a better way if they have
to learn another package management system and *I* have to spend my time
teaching people how to use it.

So -- why isn't there a universal open source package management system?
The space is large, but finite, and I don't think the growth rate, at
least in non-testing-level packages, is so high that it couldn't be
managed with open source volunteers. After all, that's the way the dozen
or so major ones are managed now. How much of this precious resource --
open source volunteer time-- is being wasted because:

a. there are three major Linux dependency trees plus the BSD Ports system,
b. every open source package has to be re-packaged and re-tested in
source form and in binary form for a number of architectures in all the
package management systems,
c. all of the major languages (Perl, Python, PHP, Tcl/Tk, Java, R) have
not only their internal dependency trees to worry about but underlying
OS dependencies as well?

Red Hat has proved in spades that this is something people will pay cold
hard cash for. No matter what anyone thinks about the superiority of
"apt" or Portage or anything else, RPM, up2date and yum are as close to
a "universal" open source package management system as I've been able to
find so far. You can load an RPM on a Debian or Gentoo box and tell the
local package manager that you've thus satisfied all the dependencies
that package satisfies. So -- why can't a Gem in fact be an RPM? Why
can't a Perl package, an R package, etc. be an RPM? Why does everyone
have to re-invent the package management system, especially when Red Hat
placed RPM and most of its infrastructure under GPL years ago?

 

[Chris Carter]

Which brings up a very interesting question/comment/pet peeve of mine.
Every Linux distro has a package management system, but there really is
no "universal" one. Debian has "apt", Red Hat and quite a few others
have something based on RPM, Gentoo has Portage, etc. OK ... that's
fine, maybe. Now the languages: Perl has CPAN and tools to make use of
it, plus ActiveState has their own Perl Package Manager and
repositories. Ruby has RubyGems, R has CRAN and its own package
management system. I don't do much with PHP, Python or Tcl, but I know
they have their own way of doing things, and that in the case ot Tcl/Tk
and Python, there's also an ActiveState way. That's decidedly *not* fine
-- I spent two days at my day job recently wrestling with just the CPAN,
Cygwin and ActiveState differences and that's just Perl! Nobody is going
to take me seriously if I suggest that Ruby is a better way if they have
to learn another package management system and *I* have to spend my time
teaching people how to use it.

So -- why isn't there a universal open source package management system?
The space is large, but finite, and I don't think the growth rate, at
least in non-testing-level packages, is so high that it couldn't be
managed with open source volunteers. After all, that's the way the dozen
or so major ones are managed now. How much of this precious resource --
open source volunteer time-- is being wasted because:

a. there are three major Linux dependency trees plus the BSD Ports system,
b. every open source package has to be re-packaged and re-tested in
source form and in binary form for a number of architectures in all the
package management systems,
c. all of the major languages (Perl, Python, PHP, Tcl/Tk, Java, R) have
not only their internal dependency trees to worry about but underlying
OS dependencies as well?

Red Hat has proved in spades that this is something people will pay cold
hard cash for. No matter what anyone thinks about the superiority of
"apt" or Portage or anything else, RPM, up2date and yum are as close to
a "universal" open source package management system as I've been able to
find so far. You can load an RPM on a Debian or Gentoo box and tell the
local package manager that you've thus satisfied all the dependencies
that package satisfies. So -- why can't a Gem in fact be an RPM? Why
can't a Perl package, an R package, etc. be an RPM? Why does everyone
have to re-invent the package management system, especially when Red Hat
placed RPM and most of its infrastructure under GPL years ago?

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

Under the same question, why can't a gem be a DEB, or why can't a perl
package be a GEM, or a gem a perl package, or an R package, or a port?

 

[matt]

Under the same question, why can't a gem be a DEB, or why can't a perl

package be a GEM, or a gem a perl package, or an R package, or a port?

The point was that there be a universal packaging system. I don't think
anyone would mind using Baltar's QQQ packing system if it was universal,
open source, extensible, and worked as advertised.

I'm all for a universal packaging system. But I'll settle just for a
universal reusable Ruby system.
Gems, Plugins, Engines, Components ... Whiskey Tango Foxtrot ?

Matt

 

[Vincent Fourmond]

Red Hat has proved in spades that this is something people will pay cold
hard cash for. No matter what anyone thinks about the superiority of
"apt" or Portage or anything else, RPM, up2date and yum are as close to
a "universal" open source package management system as I've been able to
find so far. You can load an RPM on a Debian or Gentoo box and tell the
local package manager that you've thus satisfied all the dependencies
that package satisfies. So -- why can't a Gem in fact be an RPM? Why
can't a Perl package, an R package, etc. be an RPM? Why does everyone
have to re-invent the package management system, especially when Red Hat
placed RPM and most of its infrastructure under GPL years ago?

I understand what you mean but there is need for a much better
infrastructure, then. Gems allow install to personal directories, for
instance, which RPM and DEBs obviously can't provide. Moreover, where
would you put manpages for a personal installation ?

Then, there is the so called 'maintainer scripts', that is the ones
which are dealing with updating /etc/... configuration files, setting up
rc.* bootup links, registering fonts, making stuff available for
menus... That's not a simple thing.

BTW, apt is also GPLed... Like many other package managing systems
;-)... I'm every time sceptical about one-for-all solutions: either they
don't work for everyone, either they're too complex no one will ever
choose to move from their current way system to the ultimate solution...

Cheers,

Vince

 

[dblack]

Hi --

The point was that there be a universal packaging system. I don't think
anyone would mind using Baltar's QQQ packing system if it was universal,
open source, extensible, and worked as advertised.

I'm all for a universal packaging system. But I'll settle just for a
universal reusable Ruby system.
Gems, Plugins, Engines, Components ... Whiskey Tango Foxtrot ?

Plugins, engines, and components are Rails add-ons. They don't
pertain to the matter of packaging and distributing Ruby libraries and
applications in general.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[matt]

Hi --



Plugins, engines, and components are Rails add-ons. They don't
pertain to the matter of packaging and distributing Ruby libraries and
applications in general.


David

That was my point exactly! Rails is nothing more than an extension of
Ruby via Gems packaging, but now there are more choices (or should I say
confusions), that break away from universality. I know this is a Ruby
list and not Rails, so I'll break with this: The use of a universal
packaging system would flow out to any extensions of the language as
well, so a if Gems was the way to go, then, Rails would have to as well
(in a perfect, utopian, no more advancement, socialistic kind of way),
but one that would still fit the bill of the original topic.

Matt

 

[Austin Ziegler]

That was my point exactly! Rails is nothing more than an extension of
Ruby via Gems packaging, but now there are more choices (or should I say
confusions), that break away from universality. I know this is a Ruby
list and not Rails, so I'll break with this: The use of a universal
packaging system would flow out to any extensions of the language as
well, so a if Gems was the way to go, then, Rails would have to as well
(in a perfect, utopian, no more advancement, socialistic kind of way),
but one that would still fit the bill of the original topic.

There are folks who are working on a system for enabling gems as
plug-ins to Rails, IIRC. They wanted to depend on certain things
(e.g., autorequire) that are going away, but they can enable such
things with convention and scaffolding better than they can with
misfeatures.

-austin

 

[M. Edward (Ed) Borasky]

Under the same question, why can't a gem be a DEB, or why can't a perl
package be a GEM, or a gem a perl package, or an R package, or a port?

There's no reason it *can't* ... all I am saying is that there are some
very brilliant people spending significant amounts of time packaging
valuable open source software in multiple formats, and I think that's
wrong. Most of the common gems, for example, are wrapped in Gentoo
ebuilds. A Gentoo developer, most likely a volunteer, does that, so on
my system, I can either type "gem install --remote rails" and add a line
for rails to "/etc/portage/package.provided", or "emerge -v rails".
There's probably someone else that has to do this for Debian, and for
Red Hat/Fedora/CentOS, etc. And when a new Ruby package comes out,
there's a lag as it makes its way through the gem system to a .deb, a
rpm, a .ebuild, etc. In addition, because of the labors of one
individual, a large number of R packages are packaged for Debian but
nobody has volunteered to do the same for Red Hat or Gentoo formats.

In most cases, the dependencies, both inside the Ruby infrastructure and
in the interactions between Ruby and the compilers and operating
systems, are identical -- the *only* thing that differs is the physical
format of the package and whether or not compilable language components
are pre-compiled or not. And at least for Linux, the same is true for
Perl, Python, PHP, Tcl/Tk, R, LaTeX and probably lots of others. A --
perhaps "standardized" is a better word than "universal" -- package
management system would free up developers and users to focus on
domain-specific value creation and not worry about packaging. It's all
automated anyhow. That's part of my complaint -- the numerous package
systems also consume developer resources in developing and maintaining
the automation infrastructure.

 

[Chris Carter]

There's no reason it *can't* ... all I am saying is that there are some
very brilliant people spending significant amounts of time packaging
valuable open source software in multiple formats, and I think that's
wrong. Most of the common gems, for example, are wrapped in Gentoo
ebuilds. A Gentoo developer, most likely a volunteer, does that, so on
my system, I can either type "gem install --remote rails" and add a line
for rails to "/etc/portage/package.provided", or "emerge -v rails".
There's probably someone else that has to do this for Debian, and for
Red Hat/Fedora/CentOS, etc. And when a new Ruby package comes out,
there's a lag as it makes its way through the gem system to a .deb, a
.rpm, a .ebuild, etc. In addition, because of the labors of one
individual, a large number of R packages are packaged for Debian but
nobody has volunteered to do the same for Red Hat or Gentoo formats.

In most cases, the dependencies, both inside the Ruby infrastructure and
in the interactions between Ruby and the compilers and operating
systems, are identical -- the *only* thing that differs is the physical
format of the package and whether or not compilable language components
are pre-compiled or not. And at least for Linux, the same is true for
Perl, Python, PHP, Tcl/Tk, R, LaTeX and probably lots of others. A --
perhaps "standardized" is a better word than "universal" -- package
management system would free up developers and users to focus on
domain-specific value creation and not worry about packaging. It's all
automated anyhow. That's part of my complaint -- the numerous package
systems also consume developer resources in developing and maintaining
the automation infrastructure.


--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

One of the big problems, and the reasons it may take so long for every
package/OS distro to have every package is because every distro is
different. Debian may install packages in /usr/local, BSD may choose
/opt, and every distro has their own requirements for packages.

 

[M. Edward (Ed) Borasky]

I understand what you mean but there is need for a much better
infrastructure, then. Gems allow install to personal directories, for
instance, which RPM and DEBs obviously can't provide. Moreover, where
would you put manpages for a personal installation ?

I don't remember how this is done in Debian and Red Hat/Fedora, but
Gentoo has "overlays" for this purpose -- directories outside the
"master" Portage tree where one can manage "local" or "personal"
packages, or do the same within a community.

Then, there is the so called 'maintainer scripts', that is the ones
which are dealing with updating /etc/... configuration files, setting up
rc.* bootup links, registering fonts, making stuff available for
menus... That's not a simple thing.

There is -- or was -- an effort to create a "Linux Standard Base" that
is essentially the "common underbelly" of Red Hat, SuSE and Debian
standards. I haven't heard much about that recently, so it may have
disintegrated because Red Hat is a corporation and Debian is a
not-for-profit and there wasn't any clear financial benefit to both.
Gentoo, on the other hand, is an entirely different kettle of fish. I've
been using Gentoo so long I am nearly incapable of administering a Red
Hat or Debian system at the config-file level. Yet another example of
resources wasted because of lack of standardization.

BTW, apt is also GPLed... Like many other package managing systems
;-)... I'm every time sceptical about one-for-all solutions: either they
don't work for everyone, either they're too complex no one will ever
choose to move from their current way system to the ultimate solution...

Yeah, in complex, adaptive systems like "open source software",
ultimately things change only when there's some kind of "crash" or
"market shakeout". So at the moment, we have the "local optimum" of
RubyGems for Ruby, CRAN for R, RPM, apt and Gentoo for Linux, CPAN and
ActiveState for Perl, and nobody rich enough to say, "I will only
support open source software if it's 100 percent Red Hat Enterprise
Linux compatible, packaged as RPMs, etc." In the past, though, a number
of things have been standardized because the government of the USA did
just that -- said, "if it doesn't meet this standard, you can't sell it
to us." Will that happen to Linux? It's quite possible. Will there be an
ANSI Standard for Perl, Python, PHP and Ruby? It's quite possible.

 

[James Britt]

One of the big problems, and the reasons it may take so long for every
package/OS distro to have every package is because every distro is
different. Debian may install packages in /usr/local, BSD may choose
/opt, and every distro has their own requirements for packages.

Asking for the One True Package Manager seems similar to asking for the
One True Programming Language.

Be careful what you wish for.

 

[Chris Carter]

Asking for the One True Package Manager seems similar to asking for the
One True Programming Language.

Be careful what you wish for.

--
James Britt

"Every object obscures another object."
- Luis Bunuel

Don't worry, I like both gems and deb and I wouldn't want to be stuck
with just one.

 

[M. Edward (Ed) Borasky]

One of the big problems, and the reasons it may take so long for every
package/OS distro to have every package is because every distro is
different. Debian may install packages in /usr/local, BSD may choose
/opt, and every distro has their own requirements for packages.

Yes, exactly my plea -- standardize all of this so all the distros and
all of the open source languages do it the same way. That frees a lot of
people to add other value. Red Hat can add enterprise stability value,
Debian can add "free software rigor" value, R can add open source
graphical and statistical value, Ruby can add object-oriented scripting
value, etc. And for the rest of the world, Microsoft and Apple can go on
building home entertainment centers.