Now, I didn't get too deep into Rails, but how would one practically
do that: Have several Rails projects, which all use different
versions of AR, AC etc...?
Yes. You can specify version numbers in your configuration for each
app, which is nice because it means you don't have to upgrade all your
Rails apps as soon as a new version of Rails comes out. I've done
this quite a lot (with the Ruby FAQ, RCRchive, etc.).
And how is that a major advantage over linking to them in vendor/ ?
I'm not claiming that it is. You can do whatever works for you and
you're comfortable with.
Now, that is really nice of you that you don't force me into anything.
I really mean it.
Actually, there is an important difference between require_gem and
require. A
require statement is a request to load a particular file into the
ruby image.
A require_gem statement activates (enables, selects) a versioned
package.
The key point is that a package name is not the same as a file name.
Although there is some overlap, there are many cases where this is
not true.
On the other hand, what is being accomplished for the end user _is_ the
same. I think it is foolish to have different load code dependemt on
whether a package was installed as a gem or manually. Imagine RPA
having this too. Then we'd have #require_rpa!
I think versioning is great, but maybe RubyGems went a little overboard
in separating itself from tradtional methodologies. For instance, was
it really neccessary to make binaries indirect loads? Why could Gems
have not installed libs to the standard location and just kept track of
what it put there? Versions could have been handled via directory
stucture and symlinks to the latest version. Then it would make sense
to have a #require_version method.
I agree. I don't know if it is too late to change the name or not.
···
On Sunday 17 April 2005 02:29 pm, gabriele renzi wrote:
I think I already said this once long time ago, but I forgot the
answer.. why name this method "require_gem" ? It is not the first time
people get confused about it, and I think something like "use_gem" or
"Gem.load" would be much better, showing that it does not really act
like "require" but more like a configuration step.
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
I think versioning is great, but maybe RubyGems went a little overboard
in separating itself from tradtional methodologies. For instance, was
it really neccessary to make binaries indirect loads? Why could Gems
have not installed libs to the standard location and just kept track of
what it put there? Versions could have been handled via directory
stucture and symlinks to the latest version. Then it would make sense
to have a #require_version method.
No. This is just not how versions are used in reality. I'm absolutely
puzzled by the amount of negative press gem receives for this
immensely useful feature!
I use require_gem all over the place to tie applications to versions.
For example one production server is running 6 different rails
applications, 4 of which are tied to specific older releases of gems,
redcloth and others.
Versioned libraries aren't a neat feature, they are absolutely
required for everyone who is serious about ruby. Please don't talk
this feature down because it doesn't look nice in your cron
scripts....
On 4/17/05, Jim Weirich <jim@weirichhouse.org> wrote:
On Sunday 17 April 2005 02:29 pm, gabriele renzi wrote:
> I think I already said this once long time ago, but I forgot the
> answer.. why name this method "require_gem" ? It is not the first time
> people get confused about it, and I think something like "use_gem" or
> "Gem.load" would be much better, showing that it does not really act
> like "require" but more like a configuration step.
I agree. I don't know if it is too late to change the name or not.
> I think versioning is great, but maybe RubyGems went a little
overboard
> in separating itself from tradtional methodologies. For instance,
was
> it really neccessary to make binaries indirect loads? Why could
Gems
> have not installed libs to the standard location and just kept
track of
> what it put there? Versions could have been handled via directory
> stucture and symlinks to the latest version. Then it would make
sense
> to have a #require_version method.
No. This is just not how versions are used in reality. I'm absolutely
puzzled by the amount of negative press gem receives for this
immensely useful feature!
I use require_gem all over the place to tie applications to versions.
For example one production server is running 6 different rails
applications, 4 of which are tied to specific older releases of gems,
redcloth and others.
Versioned libraries aren't a neat feature, they are absolutely
required for everyone who is serious about ruby. Please don't talk
this feature down because it doesn't look nice in your cron
scripts....
Tobias, you misunderstand me. I am all for versioning. Its the
implementation of it that I think has been problematic. Consider all
your scripts with #require_gem. Would they work in an enviroment where
the support packages were manually installed. No. You'd have to go back
and change them to #require; or have created a rescue clause to deal
with it to begin with; and thus more work to do in order to
redistribute you programs. Rather I think there should be a standard
method #require_version that Ruby supports out-of-the-box, and the libs
should be stored in the typical fashion --with links to the lastest
versions (examples of such excelent packaging systems include RubyX and
Gobo Linux). Implementing in this manner would have, indeed, still can,
thwart the issues with RUBYOPT.
T.
On 4/17/05, Jim Weirich <jim@weirichhouse.org> wrote:
On Sunday 17 April 2005 02:29 pm, gabriele renzi wrote:
I think I already said this once long time ago, but I forgot the
answer.. why name this method "require_gem" ? It is not the first time
people get confused about it, and I think something like "use_gem" or
"Gem.load" would be much better, showing that it does not really act
like "require" but more like a configuration step.
I agree. I don't know if it is too late to change the name or not.
Same here.
If everyone agrees, why not "deprecate" (a la Java) require_gem and replace it with a better name. The deprecated version can print out a warning then call the new version.
On v1.0 or when RubyGems is distributed with Ruby that deprecated method can be removed (or not...)
In my view, webcollaborator.com <http://webcollaborator.com> is a new killer
app. It is based on rails. But the killer app for ruby is Heretix the follow
on to Rubyx.
···
On 4/18/05, Trans <transfire@gmail.com> wrote:
Tobias Luetke wrote:
> > I think versioning is great, but maybe RubyGems went a little
overboard
> > in separating itself from tradtional methodologies. For instance,
was
> > it really neccessary to make binaries indirect loads? Why could
Gems
> > have not installed libs to the standard location and just kept
track of
> > what it put there? Versions could have been handled via directory
> > stucture and symlinks to the latest version. Then it would make
sense
> > to have a #require_version method.
>
> No. This is just not how versions are used in reality. I'm absolutely
> puzzled by the amount of negative press gem receives for this
> immensely useful feature!
>
> I use require_gem all over the place to tie applications to versions.
> For example one production server is running 6 different rails
> applications, 4 of which are tied to specific older releases of gems,
> redcloth and others.
>
> Versioned libraries aren't a neat feature, they are absolutely
> required for everyone who is serious about ruby. Please don't talk
> this feature down because it doesn't look nice in your cron
> scripts....
Tobias, you misunderstand me. I am all for versioning. Its the
implementation of it that I think has been problematic. Consider all
your scripts with #require_gem. Would they work in an enviroment where
the support packages were manually installed. No. You'd have to go back
and change them to #require; or have created a rescue clause to deal
with it to begin with; and thus more work to do in order to
redistribute you programs. Rather I think there should be a standard
method #require_version that Ruby supports out-of-the-box, and the libs
should be stored in the typical fashion --with links to the lastest
versions (examples of such excelent packaging systems include RubyX and
Gobo Linux). Implementing in this manner would have, indeed, still can,
thwart the issues with RUBYOPT.
T.
Tobias, you misunderstand me. I am all for versioning. Its the
implementation of it that I think has been problematic. Consider all
your scripts with #require_gem. Would they work in an enviroment where
the support packages were manually installed. No. You'd have to go back
and change them to #require; or have created a rescue clause to deal
with it to begin with; and thus more work to do in order to
redistribute you programs. Rather I think there should be a standard
method #require_version that Ruby supports out-of-the-box, and the libs
should be stored in the typical fashion --with links to the lastest
versions (examples of such excelent packaging systems include RubyX and
Gobo Linux). Implementing in this manner would have, indeed, still can,
thwart the issues with RUBYOPT.
This does sound like a very attractive alternative. Standard locations and
directory structure, plus one new directive for versioning.
I think I already said this once long time ago, but I forgot the
answer.. why name this method "require_gem" ? It is not the first time
people get confused about it, and I think something like "use_gem" or
"Gem.load" would be much better, showing that it does not really act
like "require" but more like a configuration step.
I agree. I don't know if it is too late to change the name or not.
Same here.
If everyone agrees, why not "deprecate" (a la Java) require_gem and replace it with a better name. The deprecated version can print out a warning then call the new version.
On v1.0 or when RubyGems is distributed with Ruby that deprecated method can be removed (or not...)
completely agreed, we have warnings for this, and a non '1.0' version means stuff can change slightly
···
On 4/17/05, Jim Weirich <jim@weirichhouse.org> wrote:
On Sunday 17 April 2005 02:29 pm, gabriele renzi wrote:
That's a great idea, but relying on OS dependent functionality
(symlinks) would go against ruby's nature at this point. Coming up
with a platform independant way of handling the versions is key, its
easy to think in terms of a specific environment and come up with a
solution, but to have a solution that works on nearly all platforms is
far more complex.
···
On 4/18/05, itsme213 <itsme213@hotmail.com> wrote:
"Trans" <transfire@gmail.com> wrote in message
> Tobias, you misunderstand me. I am all for versioning. Its the
> implementation of it that I think has been problematic. Consider all
> your scripts with #require_gem. Would they work in an enviroment where
> the support packages were manually installed. No. You'd have to go back
> and change them to #require; or have created a rescue clause to deal
> with it to begin with; and thus more work to do in order to
> redistribute you programs. Rather I think there should be a standard
> method #require_version that Ruby supports out-of-the-box, and the libs
> should be stored in the typical fashion --with links to the lastest
> versions (examples of such excelent packaging systems include RubyX and
> Gobo Linux). Implementing in this manner would have, indeed, still can,
> thwart the issues with RUBYOPT.
This does sound like a very attractive alternative. Standard locations and
directory structure, plus one new directive for versioning.
While there is support in Windows for linking as of NTFS 5 (see http://shell-shocked.org/article.php?id=284) it is not straighforward,
to say the least. Of course the solution is simply to have the latest
version in the standard place. (The linking is not absolutely
neccessary, but rather a convenience for managing the files.)
