Hi!
Say in appfoo I use lib_a, lib_b and lib_c.
I know if you want to use appfoo, and you have some of these libs as
gems, you can do it by inserting a "require rubygems" to the beginning
of appfoo, or running it as "ruby -rubygems <path-to-appfoo>", or by
tinkering with $RUBYOPTS.
But what if now I say *I* am aware of rubygems, and I want to let my users
not to care about whether this or that is installed as a gem or not?
One I could come up with is the following: I start apfoo like this:
%w(lib_a lib_b lib_c).each {|lib|
begin
require lib
rescue LoadError
require rubygems
require lib
end
}
-- but it's ugly, and gives a useless error message if both rubygems and
one of the libs is missing.
I also tought of
begin
require rubygems
rescue LoadError
end
require lib_a
require lib_b
require lib_c
but it pulls in rubygems unnecessarily if it's installed, but lib_* are
not gems.
The following monster:
%w(lib_a lib_b lib_c).each {|lib|
begin
require lib
rescue LoadError
begin
require rubygems
rescue LoadError
end
require lib
end
}
should work like a charm, but it's ridiculously baroque.
Any better idea?
Csaba
%w(lib_a lib_b lib_c).each {|lib|
begin
require lib
rescue LoadError
begin
require rubygems
rescue LoadError
end and retry
end
}
is slightly better, maybe.
Csaba
···
On 2005-03-17, Csaba Henk <csaba@phony_for_avoiding_spam.org> wrote:
%w(lib_a lib_b lib_c).each {|lib|
begin
require lib
rescue LoadError
begin
require rubygems
rescue LoadError
end
require lib
end
}
Csaba Henk wrote:
%w(lib_a lib_b lib_c).each {|lib|
begin
require lib
rescue LoadError
begin
require rubygems
rescue LoadError
end and retry
end
}
is slightly better, maybe.
Is testing the return value of require what you want?
#require returns false if the lib was already loaded.
Um, sorry.
%w(lib_a lib_b lib_c).each {|lib|
begin
require lib
rescue LoadError
begin
require rubygems
rescue LoadError
else true # this is also needed here...
end and retry
end
}
Csaba
···
On 2005-03-17, Csaba Henk <csaba@phony_for_avoiding_spam.org> wrote:
If the user has *no* version of the lib (i.e. not the gem and not the
regular version) you would get into an infinite loop here.
In Instiki/Pimki we tackle this like so: the tgz includes the libs
needed, while the gem version does not but does specify them as
dependencies. When starting we test if this is a gem or not and know
how to require the necessary libs. Does this help?
Cheers,
Assaph
···
On 2005-03-17, Csaba Henk <csaba@phony_for_avoiding_spam.org> wrote:
> %w(lib_a lib_b lib_c).each {|lib|
> begin
> require lib
> rescue LoadError
> begin
> require rubygems
> rescue LoadError
else true # this is also needed here...
> end and retry
> end
> }
Yes, you are right. I've already posted the correction.
Csaba
···
On 2005-03-17, Joel VanderWerf <vjoel@PATH.Berkeley.EDU> wrote:
Is testing the return value of require what you want?
#require returns false if the lib was already loaded.
> %w(lib_a lib_b lib_c).each {|lib|
> begin
> require lib
> rescue LoadError
> begin
> require rubygems
> rescue LoadError
else true # this is also needed here...
> end and retry
> end
> }
If the user has *no* version of the lib (i.e. not the gem and not the
regular version) you would get into an infinite loop here.
Again, the critique is correct. Then forget all except my first and
current post in this thread, and look at the one called "monster" in the
first post. That does the job...
In Instiki/Pimki we tackle this like so: the tgz includes the libs
needed, while the gem version does not but does specify them as
dependencies. When starting we test if this is a gem or not and know
how to require the necessary libs. Does this help?
Well, maybe I'll choose a different distribution scheme, but that's not
the heart of the matter.
The problem is that if you want to shield your users from package
mana-gem-ent issues, you have to add clutter to your code, this way or
that. As I read, you are doing this as well. I'm just looking for a
somewhat "lite" or elegant solution. No dice yet.
Maybe we have to live with it, until gems are either embraced properly
and will be integrated into official ruby or will be completely
discarded. This hanging-in-the-middle state is somewhat weird.
Csaba
···
On 2005-03-18, Assaph Mehr <assaph@gmail.com> wrote:
On 2005-03-17, Csaba Henk <csaba@phony_for_avoiding_spam.org> wrote:
Again, the critique is correct. Then forget all except my first and
current post in this thread, and look at the one called "monster" in
the
first post. That does the job...
D'oh! Should have read in time order...
> In Instiki/Pimki we tackle this like so: the tgz includes the libs
> needed, while the gem version does not but does specify them as
> dependencies. When starting we test if this is a gem or not and
know
> how to require the necessary libs. Does this help?
Well, maybe I'll choose a different distribution scheme, but that's
not
the heart of the matter.
The problem is that if you want to shield your users from package
mana-gem-ent issues, you have to add clutter to your code, this way
or
that. As I read, you are doing this as well. I'm just looking for a
somewhat "lite" or elegant solution. No dice yet.
Ha! Wait until you get into mismatching gem version management. You
_have_ to specify the version of the gem you want, otherwise clients
might have a wrong version. Seriously, see who your users are. If you
think you need to encapsulate as much as possible (i.e. non developers
then I think it's best to ship together those versions you can
trust to work with your app.
If you ever come across a better scheme (especially a lite one :),
share it with the world! There are lots of us who'd love to know.
Maybe we have to live with it, until gems are either embraced
properly
and will be integrated into official ruby or will be completely
discarded. This hanging-in-the-middle state is somewhat weird.
I think Matz is inclined to do so in the future (especially now that
RPA seems to have slowed down somewhat), but that is in the far future
probably.
Cheers,
Assaph
Thanks... at least I'm assured that in this case not I'm the one who
doesn't see the light... so we can say, "it helped"
Csaba
···
On 2005-03-18, Assaph Mehr <assaph@gmail.com> wrote:
Ha! Wait until you get into mismatching gem version management. You
_have_ to specify the version of the gem you want, otherwise clients
might have a wrong version. Seriously, see who your users are. If you
think you need to encapsulate as much as possible (i.e. non developers
then I think it's best to ship together those versions you can
trust to work with your app.
If you ever come across a better scheme (especially a lite one :),
share it with the world! There are lots of us who'd love to know.