[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: ruby gems, and the require problem (was Re: RAA Status & b

Peña, Botp

3/4/2005 3:21:00 AM

Sam Roberts [mailto:sroberts@uniserve.com] wrote:

//> +10
//> [snipped a lot of good & practical justifications]
//>
//> but i think what you are asking is rpa :-)
//
//Maybe, rpa without the admin overhead,

if one needs quality, one needs an admin :-)
i am quality sensitive, especially since i'm introducing ruby in my company.
If you think about it, the admin is there to _ease_ your job. Quality
packaging is not easy.

// where anything on RAA
//can be installed with it.

ah, rubygems at rubyforge would do fine.

but then again, who would port all those raa pckages to rubyforge/gems? An
admin again, perhaps?

kind regards -botp

//
//Cheers,
//Sam
//
25 Answers

Sam Roberts

3/4/2005 3:35:00 AM

0

Quoting botp@delmonte-phil.com, on Fri, Mar 04, 2005 at 12:21:01PM +0900:
> Sam Roberts [mailto:sroberts@uniserve.com] wrote:
>
> //> +10
> //> [snipped a lot of good & practical justifications]
> //>
> //> but i think what you are asking is rpa :-)
> //
> //Maybe, rpa without the admin overhead,
>
> if one needs quality, one needs an admin :-)

Sometimes you don't need quality.

Sometimes I need to be able to release my project, post to my mailing
list, and have my users run "favetool -get sam'sproject", and have it
work, now, whether an admin has had the time to look at my project, and
even if the project is alpha and sucks right now.

If after it is good the RPA folks want to bless it, thats great, then
you can use it at your company with an assurance of quality.

> // where anything on RAA
> //can be installed with it.
>
> ah, rubygems at rubyforge would do fine.
>
> but then again, who would port all those raa pckages to rubyforge/gems? An
> admin again, perhaps?

Well, isn't all the info in RAA sufficient to install a project?

If I can go to RAA with my web browser, go to a project page, hit the
download link, tar -xzf proj.tgz; cd proj; ruby setup.rb install...

... maybe a script could do this?

The only reason a script couldn't is that the naming conventions aren't
strong enough (some folks use setup.rb, some use install.rb), etc.

The gem tool (and rpa, I assume) when it packages something up, what it
is really doing is enforcing a structure, so tools can work with it.
This is cool.

The way I see it is:

- gems is a nice packaging system, with the unacceptable overhead of
a poorly considered versioning system

- rpa is a nice packaing system, with the unacceptable overhead of
an external evaluation process


If you could post .rpa somewhere, and the admin team could bless some
subset later, at their leisure and discretion, I'd be happy.

If gems didn't require me to change my ruby code, or hack my
environment, I'd be happy.

So close to happiness....

Cheers,
Sam

Richard Kilmer

3/4/2005 3:48:00 AM

0




On 3/3/05 10:35 PM, "Sam Roberts" <sroberts@uniserve.com> wrote:

>
> The gem tool (and rpa, I assume) when it packages something up, what it
> is really doing is enforcing a structure, so tools can work with it.
> This is cool.
>
> The way I see it is:
>
> - gems is a nice packaging system, with the unacceptable overhead of
> a poorly considered versioning system
>
> - rpa is a nice packaing system, with the unacceptable overhead of
> an external evaluation process
>

I thought for a while if we had a...

gem deploy (list of gems or --all)

...which deploys all the (ruby/native) libraries in the gems into a central
dir (like the standard /usr/local/lib/ruby/site_ruby/1.8 or something) then
you could have the normal 'require' stuff just work (removing gems from the
runtime) and making it just a deployment system. What do you think?

You could even have sets of gems based on a quality estimation (or version
compatibility) that would give you an RPA style check w/out the packaging by
a central entity.

-rich

Aria Stewart

3/4/2005 4:01:00 AM

0

> - gems is a nice packaging system, with the unacceptable overhead of
> a poorly considered versioning system
>
> - rpa is a nice packaing system, with the unacceptable overhead of
> an external evaluation process
>
>
> If you could post .rpa somewhere, and the admin team could bless some
> subset later, at their leisure and discretion, I'd be happy.

You can! It's not well documented yet, but quite possible. The rpa tool
certainly can download from any arbitrary URL.

Ari

Jim Freeze

3/4/2005 4:50:00 AM

0

* Richard Kilmer <rich@infoether.com> [2005-03-04 12:47:34 +0900]:

> I thought for a while if we had a...
>
> gem deploy (list of gems or --all)
>
> ...which deploys all the (ruby/native) libraries in the gems into a central
> dir (like the standard /usr/local/lib/ruby/site_ruby/1.8 or something) then
> you could have the normal 'require' stuff just work (removing gems from the
> runtime) and making it just a deployment system. What do you think?

I'll vote for that. ++1

Or, more likely

sudo gem deploy (list of gmes or --all)

This would make gems a great test bed. If you like it,
then put it into the system...

This should involve a relatively simple copy, right?

--
Jim Freeze
Code Red. Code Ruby

Sam Roberts

3/4/2005 4:53:00 AM

0

Quoting rich@infoether.com, on Fri, Mar 04, 2005 at 12:47:34PM +0900:
> On 3/3/05 10:35 PM, "Sam Roberts" <sroberts@uniserve.com> wrote:
>
> >
> > The gem tool (and rpa, I assume) when it packages something up, what it
> > is really doing is enforcing a structure, so tools can work with it.
> > This is cool.
> >
> > The way I see it is:
> >
> > - gems is a nice packaging system, with the unacceptable overhead of
> > a poorly considered versioning system
> >
> > - rpa is a nice packaing system, with the unacceptable overhead of
> > an external evaluation process
> >
>
> I thought for a while if we had a...
>
> gem deploy (list of gems or --all)
>
> ...which deploys all the (ruby/native) libraries in the gems into a central
> dir (like the standard /usr/local/lib/ruby/site_ruby/1.8 or something) then
> you could have the normal 'require' stuff just work (removing gems from the
> runtime) and making it just a deployment system. What do you think?

Would be a work-around, and I'm afraid it is oriented at the installer
of gems, so speaking as a library packager, it doesn't solve my
problems.

The command line tools I make that use my libraries, they do a
"require", only. If "deployment" doesn't occur, and its an optional
second step, the gem users who don't do the

gem deploy net-mdns

are going to be coming back to me and asking why my mdns.rb script won't
find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me
with having to maintain different versions of scripts and libraries -
gem using, and non-gem using.

Why isn't the entire versioning thing optional? I know I'm not the only
person who doesn't like it.

As I understand it, the real benefit to keeping the installs out of the
main tree is that it makes it easy to uninstall, not that it allows
versioning. Uninstall is very important, but there are other ways of
dealing with that.

The versioning behaviours of gems should be optional, and your deploy
should be standard. If folks need different rails installs, and they
want to use gems in their apps then they know what they are doing, they
should do a

gem install --versioned

and make sure they do a

require 'ruby_gems'
require 'rails', 0.13

at the top of their scripts.

Likewise, people who do a gem install --versioned of my libraries
(net-mdns or vPim) will KNOW that my mdns.rb script won't work out of
the box for them, they are going to have to do something to make the
scripts use the particular version - but they deliberately installed
like this, they know what the workarounds are, and why they are doing
it.

Versioning is a special case, it should be treated as such.

> You could even have sets of gems based on a quality estimation (or version
> compatibility) that would give you an RPA style check w/out the packaging by
> a central entity.


I know the rpa and gems team are friendly, so I assume that the RPA guys
real goal is a coherent set of packages. I wonder it they might not
adopt the gem package format if there was a way for them to have a named
set of gems as a "coherent version", or whatever they are looking for?
Particularly if it didn't have the versioning/API change problem?

I have the impression the rpa tool was developed as a side effect, their
primary goal was producing a stable, tested, library distribution.

Sam

Richard Kilmer

3/4/2005 5:11:00 AM

0




On 3/3/05 11:53 PM, "Sam Roberts" <sroberts@uniserve.com> wrote:

> Would be a work-around, and I'm afraid it is oriented at the installer
> of gems, so speaking as a library packager, it doesn't solve my
> problems.
>
> The command line tools I make that use my libraries, they do a
> "require", only. If "deployment" doesn't occur, and its an optional
> second step, the gem users who don't do the
>
> gem deploy net-mdns
>
> are going to be coming back to me and asking why my mdns.rb script won't
> find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me
> with having to maintain different versions of scripts and libraries -
> gem using, and non-gem using.

No...they need to get your library:

gem install net-mdns

And if they have RUBYOPT=rubygems

Their code looks like:

require 'net/mdns'

If they don't have the RUBYOPT, or don't want it, they can do:

gem deploy net-mdns

Or even more concise to download and deploy:

gem install net-mdns --deploy

With the --deploy option able to be set in the .gemrc or something.

The thing is you assume they install your net-mdns in site_ruby which may
not be what folks want. You need to have two steps...get the
library...deploy it in some directory that is in the $: path. This is the
same thing that setup.rb does (deploy into a dir...site_ruby default) Having
the RUBYOPT makes the deployment happen kinda magically at runtime as you
need it. The extra deploy step lets you do it without the magic runtime
require hack stuff. But the ability to target where to deploy (like --dir
my_test_dir) makes it rather powerful in that you can have lots of site_ruby
like dirs that hold sets of deployed gem libraries (.rb/.so) and $:.unshift
them for testing, etc.

Anyway, its a thought.

-rich

Sam Roberts

3/4/2005 5:37:00 AM

0

Quoting rich@infoether.com, on Fri, Mar 04, 2005 at 02:11:16PM +0900:
>
>
>
> On 3/3/05 11:53 PM, "Sam Roberts" <sroberts@uniserve.com> wrote:
>
> > Would be a work-around, and I'm afraid it is oriented at the installer
> > of gems, so speaking as a library packager, it doesn't solve my
> > problems.
> >
> > The command line tools I make that use my libraries, they do a
> > "require", only. If "deployment" doesn't occur, and its an optional
> > second step, the gem users who don't do the
> >
> > gem deploy net-mdns
> >
> > are going to be coming back to me and asking why my mdns.rb script won't
> > find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me
> > with having to maintain different versions of scripts and libraries -
> > gem using, and non-gem using.
>
> No...they need to get your library:
>
> gem install net-mdns
>
> And if they have RUBYOPT=rubygems

They don't, so the script won't work.

> Their code looks like:

MY CODE. IT'S MY CODE. Argh.

I wrote the script, I put it in the package, and I have to make two
versions of it, one assuming that my package was installed with ruby
gems in default mode, the other assuming ruby gems wasn't used or that
the user did "gem deploy".


gems has created two distinct dialects of ruby, one uses ruby's require,
and the other uses the gems require, of the same name. Code written in
ruby's dialect won't work with gems without hacking the code, or hacking
the environment.

Code written with the require_gems won't work for people who don't have
gems, even if they have the libraries.

Its a language split. It's a problem.

Having to set 'magic' environment variables or hack the code or command
line is a problem, not a fix.

> require 'net/mdns'
>
> If they don't have the RUBYOPT, or don't want it, they can do:

[snip] complex work arounds for a problem that should not have been
caused

> The thing is you assume they install your net-mdns in site_ruby which may
> not be what folks want. You need to have two steps...get the

NO. I don't assume they install in site_ruby, I assume they install
somewhere where ***ruby's require can find it***.

That can be anywhere, but if its not in the DEFAULT locations, then they
are doing something special, and *they* have to do something special to
compensate, like use -I or -rubygems in RUBYOPTS.

Note that that is RUBY's require, not gem's require.

People aren't using gems for the most part because they want versioning,
they are using it because they want packaging, but they are being forced
to hack their environment as if they had done a custom install into a
non-standard location, when all they wanted was a simple tool to
download and install a library.

Why?

[snip] description, yet again, of how gem's require is better than
ruby's because it implements versioning... and all you have to do is
hack your environment, change the way you call ruby scripts, or change
(just a little bit) of code in all your scripts


* Versioning must be optional.

* Installed packages must be available with RUBY's require.

* A package manager that doesn't install things by default where RUBY
can find them isn't a ruby package manager, its something else.


People who want to install packages in non-standard locations and use a
version selection system can, and if ruby gems gives a standard
framework to do that, great, but it needs to be optional.

Sam

ES

3/4/2005 5:56:00 AM

0

On Fri, March 4, 2005 5:37 am, Sam Roberts said:
> Quoting rich@infoether.com, on Fri, Mar 04, 2005 at 02:11:16PM +0900:
>>
>>
>>
>> On 3/3/05 11:53 PM, "Sam Roberts" <sroberts@uniserve.com> wrote:
>>
>> > Would be a work-around, and I'm afraid it is oriented at the installer
>> > of gems, so speaking as a library packager, it doesn't solve my
>> > problems.
>> >
>> > The command line tools I make that use my libraries, they do a
>> > "require", only. If "deployment" doesn't occur, and its an optional
>> > second step, the gem users who don't do the
>> >
>> > gem deploy net-mdns
>> >
>> > are going to be coming back to me and asking why my mdns.rb script won't
>> > find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me
>> > with having to maintain different versions of scripts and libraries -
>> > gem using, and non-gem using.
>>
>> No...they need to get your library:
>>
>> gem install net-mdns
>>
>> And if they have RUBYOPT=rubygems
>
> They don't, so the script won't work.
>
>> Their code looks like:
>
> MY CODE. IT'S MY CODE. Argh.
>
> I wrote the script, I put it in the package, and I have to make two
> versions of it, one assuming that my package was installed with ruby
> gems in default mode, the other assuming ruby gems wasn't used or that
> the user did "gem deploy".
>
>
> gems has created two distinct dialects of ruby, one uses ruby's require,
> and the other uses the gems require, of the same name. Code written in
> ruby's dialect won't work with gems without hacking the code, or hacking
> the environment.
>
> Code written with the require_gems won't work for people who don't have
> gems, even if they have the libraries.
>
> Its a language split. It's a problem.
>
> Having to set 'magic' environment variables or hack the code or command
> line is a problem, not a fix.
>
>> require 'net/mdns'
>>
>> If they don't have the RUBYOPT, or don't want it, they can do:
>
> [snip] complex work arounds for a problem that should not have been
> caused
>
>> The thing is you assume they install your net-mdns in site_ruby which may
>> not be what folks want. You need to have two steps...get the
>
> NO. I don't assume they install in site_ruby, I assume they install
> somewhere where ***ruby's require can find it***.
>
> That can be anywhere, but if its not in the DEFAULT locations, then they
> are doing something special, and *they* have to do something special to
> compensate, like use -I or -rubygems in RUBYOPTS.
>
> Note that that is RUBY's require, not gem's require.
>
> People aren't using gems for the most part because they want versioning,
> they are using it because they want packaging, but they are being forced
> to hack their environment as if they had done a custom install into a
> non-standard location, when all they wanted was a simple tool to
> download and install a library.
>
> Why?
>
> [snip] description, yet again, of how gem's require is better than
> ruby's because it implements versioning... and all you have to do is
> hack your environment, change the way you call ruby scripts, or change
> (just a little bit) of code in all your scripts
>
>
> * Versioning must be optional.
>
> * Installed packages must be available with RUBY's require.
>
> * A package manager that doesn't install things by default where RUBY
> can find them isn't a ruby package manager, its something else.
>
>
> People who want to install packages in non-standard locations and use a
> version selection system can, and if ruby gems gives a standard
> framework to do that, great, but it needs to be optional.

Somewhat heated this discussion of yours.

I'm certainly in favour of the --deploy scheme; the whole changing of the
require subsystem is what's kept me off gems so far. It just conjures images
from "Invasion of the body snatchers," for some reason (the remake, if you must
know).

The rest of the gem stuff being absolutely brilliant, this has stuck out like
a mammoth in a peapod; I never understood why it wasn't the default behaviour
to just collect all the packages to some directory and then include that in
the search path.

> Sam

E

Jim Freeze

3/4/2005 5:57:00 AM

0

* Sam Roberts <sroberts@uniserve.com> [2005-03-04 14:37:28 +0900]:

> MY CODE. IT'S MY CODE. Argh.
>
> I wrote the script, I put it in the package, and I have to make two
> versions of it, one assuming that my package was installed with ruby
> gems in default mode, the other assuming ruby gems wasn't used or that
> the user did "gem deploy".

If I understand correctly, you shouldn't have to make
to versions of a script that is in a library.
The person writing code calling your lib needs
to be careful (see below), but your library
(ie code in your package) shouldn't have to
be conscious that it is a gem or not.

> gems has created two distinct dialects of ruby, one uses ruby's require,
> and the other uses the gems require, of the same name. Code written in
> ruby's dialect won't work with gems without hacking the code, or hacking
> the environment.
>
> Code written with the require_gems won't work for people who don't have
> gems, even if they have the libraries.

Is it really that much trouble to write:

begin
require 'some-lib'
rescue LoadError
require 'rubygems'
require 'some-lib'
end

Maybe we could get this added to the std distro, assuming
the gems ships with the std distro.

--
Jim Freeze
Code Red. Code Ruby

Jim Freeze

3/4/2005 6:00:00 AM

0

* Richard Kilmer <rich@infoether.com> [2005-03-04 14:11:16 +0900]:

> gem install net-mdns --deploy

Rich

I know this is a rather new idea, but would a deploy feature
have the option of installing with or without a version?
Seems like a nice thing, but maybe too complicated.

--
Jim Freeze
Code Red. Code Ruby