Re: Bug#293055: Progress with rails?
Yo,
I'm quite busy atm. but I've spent a significant amount of time thinking about
Ruby+packaging+RubyGems, so maybe I can add something to the discussion.
On Sat, Feb 12, 2005 at 03:09:16PM +0100, Adeodato Simó wrote:
> > # rubygems.rb - dummy lib
>
> > warn "Rubygems required but not installed, falling back to local installed libs."
>
> I would consider dropping this one warning, it would get triggered too
> often for nothing AIUI.
>
> > module Kernel
>
> > def require_gem(path)
> > warn "require_gem should not be used when RubyGems are not installed, "
> > "falling back to local installed libs."
> > require(path)
> > end
>
> > end
> > ---
>
> > It would bring source compatibility for Debian for both gem and not
> > non-gem applications/libraries. However, this too, is a hack and I am
> > not sure what will happen if someone installs RubyGems from
> > source/natively.
This won't always work, unfortunately.
require_gem expects the name of the RubyGems *package* as the arg, which
is often not the name of the corresponding .rb file. Note for instance
the asymmetry
require_gem 'diff-lcs' vs require 'diff/lcs'
There are actually two issues; require_gem X is NOT always equivalent
to locating X in the gems/ directory, adding the path to $: and loading
it, because:
(1) the namespaces are different (RubyGems packages vs .rb files)
(2) require_gem also features 'auto_require' to have several .rb files
loaded when a gem is requested.
Regarding (2), I think it's a misfeature, because you can get something
equivalent in a compatible way (with the rest of the world, that is)
by creating a mylib.rb file which loads mylib/{foo,bar,baz}.rb. This is
what people have been doing for a long time and it worked just fine.
> Well, if the users install RubyGems by hand, it will be under
> /usr/local/lib/site_ruby/1.8, which takes precedence over distribution
> paths, so there should be no problem. And the rubygems.deb package
> could divert the file rubygems.rb. (We are assuming that the dummy
> rubygems.rb file would belong in libruby1.8, right?)
>
> The real improvement/innovation here (and we could learn about how
> does Perl in Debian do it, I'm not familiar at all with it) would be
> that rubygems.deb (and rpa-base.deb?) provided a mechanism to make
> dpkg aware of the non-deb things installed, which would be a plus for
> installing RubyGems and RPA from Debian instead of by hand. (I'm being
> intentionally vague here...)
In the case of rpa-base, the idea is using Debian's toolchain; that is,
RPA should provide the input you need by creating Debianized sources
that would then need to be reviewed by a Debian developer. In the long
term, RPA could provide infrastructure to let repackagers create their
vendor branches directly in RPA.
"We" (RPA) think that the "native" port/package management tools are
normally preferable. rpa-base will be a good fallback for platforms
without an adequate one (win32 to begin with) or those willing to let
rpa-base manage their Ruby installation.
In the case of RubyGems, it seems Chad wanted to generate .deb files
from RubyGems packages directly. However, I believe the RubyGems Team
have not understood why RubyGems packages are not a good format for
upstream as they are right now. Just to name some major problems:
* RubyGems packages are, well, dependent on RubyGems in general
* RubyGems' "1 version == 1 dir" model encourages nasty assumptions
about the directory layout. Note for instance that RubyGems has no
support for DATADIR, so people end up having to change their code
to do things like File.open(File.join(File.dirname(__FILE_), "..",
"..", "data", "foo", "bla.dat"))
* The RubyGems process is not idempotent. In general, you cannot rebuild
a RubyGems package from itself. Of course, this is something one can
expect from *packages* as opposed to pristine sources, but RubyGems
aims at replacing other formats for upstream.
...
In general, developers are being told that they need not think about
distribution and deployment, because RubyGems is the "Ruby standard" and
the RubyGems Team have already solved that problem for them. So they
end up modifying their sw. to make it RubyGems-compatible. At the end
of the day, repackagers have to undo those modifications before even
starting to do their real work. This was my experience when packaging
stuff for RPA (some 150+ libs/apps, with several RubyGems-dependent
stuff, including libs which were only available in .gem format).
The good news is the RubyGems team are committed to making RubyGems
repackager-friendly, the bad one that they haven't done anything about it
for quite some time, and some of the required changes would go against
the design choices from the "late night pub hacking sessions" during
RubyConf03. In the past, requests for less fundamental modifications
have met very strong opposition.
On top of that, the RubyGems Team consider RubyGems pretty much
feature-complete, and the current version is 0.8.4. It is very unlikely
that they do any significant modifications before 1.0.0, at the risk of
disturbing their current user base.
> > Hmm, the user quide still does so. Maybe this is because require_gem can
> > do something extra, namely one can add a version requirement:
>
> > require_gem "gem_name", [version_requirement]
>
> Hmmm, we could check if it could be possible to implement a proper
> 'require_gem' in the dummy rubygems.rb file, that would check the
> version of the non-gem version. Doesn't sound easy, but a little of
> thought could be put into it.
>
> And that's enough for crazy ideas already. ;-)
IMHO the "cherry picking" versioning model introduced by RubyGems should
not be promoted. Debian's own mechanisms should be enough to resolve
lib. references "statically". Cherry picking is useful in some
situations but I believe it's not the mechanism that should be used by
default/the only one.
--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/
Reply to: