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


 

Forums >

comp.lang.ruby

Gem Namespaces

Trans

2/3/2007 5:43:00 PM

Hi--

I know I will probably be lambasted by the usual lambasting sort,
nonetheless I think its worth suggesting that all gems have a project
namespace. As things stand a project on Rubyforge can create gems with
any name at all --which can readily conflict with gems in another
project. A few projects in particular suck up lots of name real-
estate, in just 3 projects alone one can find 59 gems, some with names
as simple as "traits".

I realize the community has done pretty well in working together to
avoid conflicts. But as RubyForge grows this becomes increasingly more
difficult -- not to mention annoying.

So I'm thinking perhaps gems should be referenced with a namspece
attached. For example instead of

gem install traits

do:

gem install codeforpeople:traits

Perhaps we could still use the former too, but if there is conflict
the gem app can ask us which project is intended. Or something to that
effect. Has anyone else considered remedies for this?

Thanks,
T.
8 Answers

Austin Ziegler

2/3/2007 5:50:00 PM

0

On 2/3/07, Trans <transfire@gmail.com> wrote:
> So I'm thinking perhaps gems should be referenced with a namspece
> attached. For example instead of
>
> gem install traits
>
> do:
>
> gem install codeforpeople:traits
>
> Perhaps we could still use the former too, but if there is conflict
> the gem app can ask us which project is intended. Or something to that
> effect. Has anyone else considered remedies for this?

RubyForge currently ensures that the only traits gem that will exist
on RubyForge is the one from codeforpeople -- because they were the
first to release such. It's not quite a namespace, but it prevents the
conflict you were talking about.

There are, I think, worse problems than possible gem name collisions
(require-able contents collisions are more likely, IMO).

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Trans

2/3/2007 7:03:00 PM

0



On Feb 3, 12:49 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:

> RubyForge currently ensures that the only traits gem that will exist
> on RubyForge is the one from codeforpeople -- because they were the
> first to release such. It's not quite a namespace, but it prevents the
> conflict you were talking about.

That's too bad, I think. For instance, I have my own rendition of
rubyforge.rb that I made based on the Ara's original. This script used
to be tucked away in the Reap project, but I'm reorgainizing my tools
and I was thinking of releasing this separately. But what wll I call
it since "rubyforge" is already used? Are other's going to be happy if
I call it "rubyforge2" ?

> There are, I think, worse problems than possible gem name collisions
> (require-able contents collisions are more likely, IMO).

Luckily if two projects have similar names it probably b/c they serve
nearly the same purpose and you'd use only one or the other. But your
right, that' can be a problem too.

T.

Tom Copeland

2/3/2007 11:59:00 PM

0

On Sun, 2007-02-04 at 02:43 +0900, Trans wrote:
> I know I will probably be lambasted by the usual lambasting sort,
> nonetheless I think its worth suggesting that all gems have a project
> namespace. As things stand a project on Rubyforge can create gems with
> any name at all --which can readily conflict with gems in another
> project. A few projects in particular suck up lots of name real-
> estate, in just 3 projects alone one can find 59 gems, some with names
> as simple as "traits".

A note on this - anyone on RubyForge can create and release a gem called
anything they want. I could create a Rails 4.2 gem and release it on my
"foo" project. It just won't get deployed to the RubyForge gem index.
But people can still come to my "foo" project and download the gem via
the regular file download pages and then install it.

Another option is to set up a gem index on your project's virtual host -
foo.rubyforge.org - and folks can install with gem --source.

Those options may alleviate the namespacing problem somewhat; food for
thought, anyhow.

Yours,

tom

Eric Hodel

2/4/2007 12:55:00 AM

0

On Feb 3, 2007, at 11:02, Trans wrote:
> I have my own rendition of rubyforge.rb that I made based on the
> Ara's original. This script used to be tucked away in the Reap
> project, but I'm reorgainizing my tools
> and I was thinking of releasing this separately. But what wll I
> call it since "rubyforge" is already used? Are other's going to be
> happy if I call it "rubyforge2" ?

Why don't you instead adapt your changes into a patch and file it in
the codeforpeople tracker? There's no sense in having an extra
version lying around just because you added one or two things.

Trans

2/4/2007 1:37:00 AM

0



On Feb 3, 7:55 pm, Eric Hodel <drbr...@segment7.net> wrote:
> On Feb 3, 2007, at 11:02, Trans wrote:
>
> > I have my own rendition of rubyforge.rb that I made based on the
> > Ara's original. This script used to be tucked away in the Reap
> > project, but I'm reorgainizing my tools
> > and I was thinking of releasing this separately. But what wll I
> > call it since "rubyforge" is already used? Are other's going to be
> > happy if I call it "rubyforge2" ?
>
> Why don't you instead adapt your changes into a patch and file it in
> the codeforpeople tracker? There's no sense in having an extra
> version lying around just because you added one or two things.

It not just one or two things, though. It's a good bit different in
how it deals with config information. Mine was based on pre 0.0.0
version and I made modification in scraping project information too
but in a very different way than codeforpeople, ie. it doesn't require
the setup stage, but scrapes the info on the fly and just logs in
automatically when you do stuff. I'd be happy to contribute it, but it
is a significant shift in functionality (though the fundamentals are
still the same -- for example I recently reused the URI and post news
code from the lastest codeforpeople version quite easily).

Aside, I sort of wish it didn't use HTTPAccess2, it seems quite a
hefty lib for what rubyforge.rb is using it for. But I'm not sure,
maybe there's no better option.

T.

Eric Hodel

2/5/2007 7:04:00 PM

0

On Feb 3, 2007, at 17:37, Trans wrote:
> On Feb 3, 7:55 pm, Eric Hodel <drbr...@segment7.net> wrote:
>> On Feb 3, 2007, at 11:02, Trans wrote:
>>
>>> I have my own rendition of rubyforge.rb that I made based on the
>>> Ara's original. This script used to be tucked away in the Reap
>>> project, but I'm reorgainizing my tools
>>> and I was thinking of releasing this separately. But what wll I
>>> call it since "rubyforge" is already used? Are other's going to be
>>> happy if I call it "rubyforge2" ?
>>
>> Why don't you instead adapt your changes into a patch and file it in
>> the codeforpeople tracker? There's no sense in having an extra
>> version lying around just because you added one or two things.
>
> It not just one or two things, though. It's a good bit different in
> how it deals with config information. Mine was based on pre 0.0.0
> version and I made modification in scraping project information too
> but in a very different way than codeforpeople, ie. it doesn't require
> the setup stage, but scrapes the info on the fly and just logs in
> automatically when you do stuff. I'd be happy to contribute it, but it
> is a significant shift in functionality (though the fundamentals are
> still the same -- for example I recently reused the URI and post news
> code from the lastest codeforpeople version quite easily).

Ryan implemented an auto-config, but still as a separate stage... It
would have been nice to know about your patch before we did it. I'd
still take a look.

> Aside, I sort of wish it didn't use HTTPAccess2, it seems quite a
> hefty lib for what rubyforge.rb is using it for. But I'm not sure,
> maybe there's no better option.

HTTPAccess2 has sessions stuff built-in. *shrug*.

Ara.T.Howard

2/5/2007 7:15:00 PM

0

Trans

2/5/2007 10:48:00 PM

0



On Feb 5, 2:15 pm, ara.t.how...@noaa.gov wrote:
> On Tue, 6 Feb 2007, Eric Hodel wrote:
>
> > Ryan implemented an auto-config, but still as a separate stage... It would
> > have been nice to know about your patch before we did it. I'd still take a
> > look.
>
> i'm with eric. when you take a wrong turn on the trail turn back fast! not
> that i'm saying YOU took a wrong turn, but we've forked and, the longer we
> continue, the harder it will be. rubyforge cannot possibly by important
> enough as a script to require a forked project right?

fair enough. I'll send you a copy of mine and see waht we can work
out.

> >> Aside, I sort of wish it didn't use HTTPAccess2, it seems quite a hefty lib
> >> for what rubyforge.rb is using it for. But I'm not sure, maybe there's no
> >> better option.
>
> > HTTPAccess2 has sessions stuff built-in. *shrug*.
>
> i initiallly used http-access2 for 4 reasons
>
> - proxy support
>
> - debug support. i had to use this heavily as http-access2 itself had
> several bugs i worked in runtime patches for
>
> - cookie support
>
> - redirection support
>
> these were all things i had no interest in maintaining myself.

those are all good reasons.

> it would easy to replace http-access2 with something else if you have a
> suggestion?

i don't know of any.

t.