Gem Namespaces

[Trans]

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.

 

[Austin Ziegler]

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

 

[Trans]

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]

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]

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]

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]

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]

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?

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.

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

cheers.

-a

 

[Trans]

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.

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.