If I use RubyGems to document a dependency to another gem then am I
correct in thinking it’s not enough to simply have had that library
installed – I explicitly need that gem, right? I mean, Lafcadio
depends on REXML and when I try to install the Lafcadio gem it tells
me it can’t find the REXML gem. REXML is already installed (I’m using
Ruby 1.8 so it’s part of the std library) but I’ll need to install the
REXML gem so that my Lafcadio gem will work, right?
Related to that: Any ideas as to where in the future you see some
sort of auto-dependency install mgmt happening?
1. If I use RubyGems to document a dependency to another gem then am I
correct in thinking it’s not enough to simply have had that library
installed – I explicitly need that gem, right? I mean, Lafcadio
depends on REXML and when I try to install the Lafcadio gem it tells
me it can’t find the REXML gem. REXML is already installed (I’m using
Ruby 1.8 so it’s part of the std library) but I’ll need to install the
REXML gem so that my Lafcadio gem will work, right?
That’s correct. We can handle documented requirements which aren’t
managed dependencies, but if you want real dependency management, the
dependencies (for now at least) have to be Gems.
2. Related to that: Any ideas as to where in the future you see some
sort of auto-dependency install mgmt happening?
Do you mean like:
gem --remote-install somegem
…and it downloads and installs the gem and all of its dependencies? If
so, you can already do this (of course, it needs to have the kinks worked
out, but the basic functionality has been there since RubyConf).
Gems dependency checking is only for other Gems. If you have libraries
installed in the std lib or the site_ruby directory, you do not specify
a dependency on them (and Gems does not manage them). Since REXML is
part of the std lib, and since that is the only thing you depend on, you
don’t specify any Gems dependency.
-rich
···
On Dec 23, 2003, at 12:01 PM, Francis Hwang wrote:
If I use RubyGems to document a dependency to another gem then am I
correct in thinking it’s not enough to simply have had that library
installed – I explicitly need that gem, right? I mean, Lafcadio
depends on REXML and when I try to install the Lafcadio gem it tells
me it can’t find the REXML gem. REXML is already installed (I’m using
Ruby 1.8 so it’s part of the std library) but I’ll need to install the
REXML gem so that my Lafcadio gem will work, right?
This is the situation I tried to point out at RubyConf that I’d seen with
RedHat’s rpm package manager. Namely that if I’ve already installed a
piece of software, without using the package manager, what will happen
when I try to install something else that does use the package manager?
I don’t really know how to solve it unless you can fake out the package
manager (gem-thingy) or have the gem producer provide some sort of test
that the gem-thingy can use at install time to check for the existence of
a piece of software that was installed manually. Maybe a filename/pathname
that it can check for as a last resort if the gem for a needed something
isn’t found.
Joey
···
On Wed, 24 Dec 2003, Francis Hwang wrote:
If I use RubyGems to document a dependency to another gem then am I
correct in thinking it’s not enough to simply have had that library
installed – I explicitly need that gem, right? I mean, Lafcadio
depends on REXML and when I try to install the Lafcadio gem it tells
me it can’t find the REXML gem. REXML is already installed (I’m using
Ruby 1.8 so it’s part of the std library) but I’ll need to install the
REXML gem so that my Lafcadio gem will work, right?
If I use RubyGems to document a dependency to another gem then am I
correct in thinking it’s not enough to simply have had that library
installed – I explicitly need that gem, right? I mean, Lafcadio
depends on REXML and when I try to install the Lafcadio gem it tells
me it can’t find the REXML gem. REXML is already installed (I’m using
Ruby 1.8 so it’s part of the std library) but I’ll need to install the
REXML gem so that my Lafcadio gem will work, right?
Related to that: Any ideas as to where in the future you see some
sort of auto-dependency install mgmt happening?
Francis
Another cool feature would be to bundle all the necessary tools to
compile new RubyGems into the Windows installer version. That way
windows users who didn’t know how to set these things up could get up
and running quickly with Ruby. I think this would do a lot to promote
Ruby use.
Isn’t this a relatively straightforward ‘require ’ test? I don’t
know exactly how CPAN decides if a package is installed or not, but it has
always seemed as though it does something along the lines of:
perl -M
if [ $? != 0]; then
echo Missing pkg
blah blah
fi
This is certainly an easy thing to do in ruby:
begin
require ‘’
rescue
give a warning, maybe try to install the lib, and then
redo this section, probably
end
Luke
···
On Wed, 24 Dec 2003, Joey Gibson wrote:
On Wed, 24 Dec 2003, Francis Hwang wrote:
If I use RubyGems to document a dependency to another gem then am I
correct in thinking it’s not enough to simply have had that library
installed – I explicitly need that gem, right? I mean, Lafcadio
depends on REXML and when I try to install the Lafcadio gem it tells
me it can’t find the REXML gem. REXML is already installed (I’m using
Ruby 1.8 so it’s part of the std library) but I’ll need to install the
REXML gem so that my Lafcadio gem will work, right?
This is the situation I tried to point out at RubyConf that I’d seen with
RedHat’s rpm package manager. Namely that if I’ve already installed a
piece of software, without using the package manager, what will happen
when I try to install something else that does use the package manager?
I don’t really know how to solve it unless you can fake out the package
manager (gem-thingy) or have the gem producer provide some sort of test
that the gem-thingy can use at install time to check for the existence of
a piece of software that was installed manually. Maybe a filename/pathname
that it can check for as a last resort if the gem for a needed something
isn’t found.
–
The Washington Bullets are changing their name. The owners no
longer want their team’s name to be associated with crime. So from
now on the team will be known as The Bullets.
– Paul Harvey, quoting Argus Hamilton
If I use RubyGems to document a dependency to another gem then am I
correct in thinking it’s not enough to simply have had that library
installed – I explicitly need that gem, right? I mean, Lafcadio
depends on REXML and when I try to install the Lafcadio gem it tells
me it can’t find the REXML gem. REXML is already installed (I’m using
Ruby 1.8 so it’s part of the std library) but I’ll need to install the
REXML gem so that my Lafcadio gem will work, right?
This is the situation I tried to point out at RubyConf that I’d seen with
RedHat’s rpm package manager. Namely that if I’ve already installed a
piece of software, without using the package manager, what will happen
when I try to install something else that does use the package manager?
I don’t really know how to solve it unless you can fake out the package
manager (gem-thingy) or have the gem producer provide some sort of test
that the gem-thingy can use at install time to check for the existence of
a piece of software that was installed manually. Maybe a filename/pathname
that it can check for as a last resort if the gem for a needed something
isn’t found.
Something like:
#let’s see if they’ve already got rexml:
begin
require ‘rexml’
rescue MissingPackage #or whatever it’s really called #it’s really not here, so go look for one to download
…
else #it is here already, maybe check out the version somehow #otherwise everything should be OK
end
This is the situation I tried to point out at RubyConf that I’d seen with
RedHat’s rpm package manager. Namely that if I’ve already installed a
piece of software, without using the package manager, what will happen
when I try to install something else that does use the package manager?
I don’t really know how to solve it unless you can fake out the package
manager (gem-thingy) or have the gem producer provide some sort of test
that the gem-thingy can use at install time to check for the existence of
a piece of software that was installed manually. Maybe a
filename/pathname
that it can check for as a last resort if the gem for a needed something
isn’t found.
Something like:
#let’s see if they’ve already got rexml:
begin
require ‘rexml’
rescue MissingPackage #or whatever it’s really called #it’s really not here, so go look for one to download
…
else #it is here already, maybe check out the version somehow #otherwise everything should be OK
end
This is too simple. RubyGems should also check that the proper version is
installed.
I think that RubyGems should optionally allow the user to inform it of a
manual installation when a gem is not found, prompting the user for the need
information (like version number installed). That particular gem would then
be entered into its gem-database as having been installed manually for
future use.
Correspondingly, there should be an option to remove such a
manual-installation-entry from the RubyGems database.
This is too simple. RubyGems should also check that the proper version is
installed.
I think that RubyGems should optionally allow the user to inform it of a
manual installation when a gem is not found, prompting the user for the need
information (like version number installed). That particular gem would then
be entered into its gem-database as having been installed manually for
future use.
Correspondingly, there should be an option to remove such a
manual-installation-entry from the RubyGems database.
This is too simple. RubyGems should also check that the proper
version is
installed.
I think that RubyGems should optionally allow the user to inform it
of a
manual installation when a gem is not found, prompting the user for
the need
information (like version number installed). That particular gem
would then
be entered into its gem-database as having been installed manually for
future use.
Correspondingly, there should be an option to remove such a
manual-installation-entry from the RubyGems database.
I was thinking along these same lines.
Well, when we were discussing this at RubyConf03 we decided that Gems
would
run along side the existing mechanisms for installation/management of
libraries.
In other words, the ruby/lib/1.8 and ruby/lib/site_ruby/1.8 would remain
as they are, and if you install a Ruby library with setup.rb or
install.rb
it would operate just like now. If you install a Gem, however, it
installs in
a separate directory. There is no ‘database’ per se. There is a
directory
of .gemspec YAML files that are checked and that forms your database of
installed
Gems (of course, it supports multiple directories).
Chad and I have discussed getting all the standard libraries and
forming a Gem or
set of Gems with them. I think that would be quite cool, but, again,
we are
not trying to replace the current LOAD_PATH, just augment it to make
management
of libraries easier and more powerful. Gems supports versioning, the
standard
library system does not. I mean, as a short term solution we could
create a Gem
that picks up the Ruby version and you just do:
require_gem ‘ruby’, ‘> 1.8’
or something…of course that .gemspec would not actually modify the
LOAD_PATH
as other Gems do, because Ruby’s libraries are already in the
LOAD_PATH. If
you then place a dependency on ruby 1.8 (or 1.8.1, etc) you would be
guaranteed
to have REXML, WEBrick, XMLRPC4R, etc.
Hm…now that I think of it, that is pretty sweet. If folks thinks
this is
good, it could be done quite quickly.
dependencies.each do |lib, tests|
begin
has_gem(lib => tests)
rescue RubyGems::NotInstalledError
begin
require lookup_lib(lib)
tests.each { |test, version| test_version(test, version) }
rescue LoadError, RubyGems::VersionError
download_gem(lib, version)
end
end
end
lookup_lib would be something like:
def lookup_lib(lib)
RubyGems::KNOWN_LIBS[lib] or lib
end
Where KNOWN_LIBS might look like:
RubyGems::KNOWN_LIBS[‘rexml’] = ‘rexml/document’
One of the things that should be encouraged is perhaps creating a
VERSION constant as a VersionTuple (see the attached file).
This would mean that you don’t have to enter manual-installation-
entry stuff. It would be a bit more complex for things that require
an external library (e.g., compiled RubyGems, such as libxml or
libxslt), but the pattern is the same.
Another idea is to have a lightweight gem manifest, downloadable as a
separate entity, that would check for all the files in the gem, and if
you have them all, spring the gem into existence. That way, if you
manually install a package, you can use its manifest to make it look
like you installed it from a gem all along.
library system does not. I mean, as a short term solution we could
create a Gem that picks up the Ruby version and you just do:
require_gem ‘ruby’, ‘> 1.8’
or something…of course that .gemspec would not actually modify the
LOAD_PATH as other Gems do, because Ruby’s libraries are already in
the LOAD_PATH. If you then place a dependency on ruby 1.8 (or 1.8.1,
etc) you would be guaranteed to have REXML, WEBrick, XMLRPC4R, etc.
Hm…now that I think of it, that is pretty sweet. If folks thinks
this is good, it could be done quite quickly.
The issue is that what a Gem IS is a directory of Ruby files, along with
metadata about that directory. If you just have an arbitrary directory
of Ruby files (like in site_ruby) you would have to create metadata for
that. The main benefit of a Gem is to allow you to add/remove libraries
easily (which cannot be done now because they are all added to the same
dir). It does this by managing the LOAD_PATH. A side benefit is the
ability to have versions of Gems, although only one version of a Gem
can be loaded per Ruby interpreter.
Gems is not a replacement for ‘require’, and it is require with a
LoadError that aids you in knowing whether a library is installed
or not.
-rich
···
On Dec 26, 2003, at 5:01 PM, Martin DeMello wrote:
library system does not. I mean, as a short term solution we could
create a Gem that picks up the Ruby version and you just do:
require_gem ‘ruby’, ‘> 1.8’
or something…of course that .gemspec would not actually modify the
LOAD_PATH as other Gems do, because Ruby’s libraries are already in
the LOAD_PATH. If you then place a dependency on ruby 1.8 (or 1.8.1,
etc) you would be guaranteed to have REXML, WEBrick, XMLRPC4R, etc.
Hm…now that I think of it, that is pretty sweet. If folks thinks
this is good, it could be done quite quickly.
Another idea is to have a lightweight gem manifest, downloadable as a
separate entity, that would check for all the files in the gem, and if
you have them all, spring the gem into existence. That way, if you
manually install a package, you can use its manifest to make it look
like you installed it from a gem all along.
IMO it would be best to have some kind of database that stores module
name, version with a md5 checksum of the files. Then if you failed to
find a gem, you could fall back on a search of your lib and site_lib
directories for the module, compare checksums to determine version, and
then validate the requirement. It’s ugly, but it’s temporary. It’s much,
much better than depending on the user; my experience in the perl
community has taught me that most users don’t have a clue what modules
they have installed, what versions they have, or how determine any of
the aforesaid. If you do depend on the user, you should also be prepared
for users complaining they accidently entered the wrong info, and now
they don’t know how to fix it, etc. Either way it will likely be a PIA
until gems fully mature and take over as THE means of distributing
ruby modules.
library system does not. I mean, as a short term solution we could
create a Gem that picks up the Ruby version and you just do:
require_gem ‘ruby’, ‘> 1.8’
or something…of course that .gemspec would not actually modify the
LOAD_PATH as other Gems do, because Ruby’s libraries are already in
the LOAD_PATH. If you then place a dependency on ruby 1.8 (or 1.8.1,
etc) you would be guaranteed to have REXML, WEBrick, XMLRPC4R, etc.
Hm…now that I think of it, that is pretty sweet. If folks thinks
this is good, it could be done quite quickly.
Another idea is to have a lightweight gem manifest, downloadable as a
separate entity, that would check for all the files in the gem, and if
you have them all, spring the gem into existence. That way, if you
manually install a package, you can use its manifest to make it look
like you installed it from a gem all along.
How well will this method scale? If I’m understanding you correctly, the
search path will grow for each module installed. This means the more
modules you install the longer it will take to search for modules to
load. Or did you mean something different when you said “managing the
LOAD_PATH”?
Regards,
Randy.
···
On 12/26/2003 7:23 PM, Richard Kilmer wrote:
On Dec 26, 2003, at 5:01 PM, Martin DeMello wrote:
library system does not. I mean, as a short term solution we could
create a Gem that picks up the Ruby version and you just do:
require_gem ‘ruby’, ‘> 1.8’
or something…of course that .gemspec would not actually modify the
LOAD_PATH as other Gems do, because Ruby’s libraries are already in
the LOAD_PATH. If you then place a dependency on ruby 1.8 (or 1.8.1,
etc) you would be guaranteed to have REXML, WEBrick, XMLRPC4R, etc.
Hm…now that I think of it, that is pretty sweet. If folks thinks
this is good, it could be done quite quickly.
Another idea is to have a lightweight gem manifest, downloadable as a
separate entity, that would check for all the files in the gem, and if
you have them all, spring the gem into existence. That way, if you
manually install a package, you can use its manifest to make it look
like you installed it from a gem all along.
The issue is that what a Gem IS is a directory of Ruby files, along with
metadata about that directory. If you just have an arbitrary directory
of Ruby files (like in site_ruby) you would have to create metadata for
that. The main benefit of a Gem is to allow you to add/remove libraries
easily (which cannot be done now because they are all added to the same
dir). It does this by managing the LOAD_PATH.