Good gem names are becoming increasingly rare.

[Samuel Williams]

Good names for gems on RubyGems.org are becoming increasingly hard to figure out.

Hosting a private gem server is one option, but has anyone considered whether per-user prefixing is still a good idea?

e.g.

gem "username/gemname"

gem "username-gemname"

or

gem "https://gemserver/gemname"

Rather than proposing a solution to this problem, I'm just wondering if anyone else is thinking about these issues and had any ideas.

Kind regards

Samuel

[Tyler Knappe]

There has been quite a bit of discussion about prefixing gems in some unique way.  However, I don't think username prefixing is encouraged:

https://groups.google.com/d/msg/rubygems-org/Z7V63f_KUXU/p248WmNFa3MJ

What is the driver?  What gem name were you looking for but found was taken?  There are known spam accounts, some holding hundreds of names.  It is possible that one of the gem names you're looking to use is owned by one of these accounts.  If that is the case, I'm sure that the name can be freed up.

--
You received this message because you are subscribed to the Google Groups "rubygems.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nick Quaranto]

Is there a specific name you had trouble getting? And yes, this is the problem with one namespace, but it's been the same problem for as long as RubyGems has existed. I think we should talk about this going forward though. It's going to be an ongoing issue.

Something I strongly believe in: it doesn't matter what the name is, if the code is great, people will use it. I mean seriously, most Rails apps out there run on Unicorns and Rainbows. :)

Nick

[Samuel Williams]

The specific problem I have is with the gem called "build". I want to use it for a build system that I've been working on. This name has been sat on since 2012 with no activity, no actual release, etc. I contact the author, he was a reasonable guy, but he said because they have a commercial project they are using the name internally and wanted to publish the code but never got around to it. Source code is not available anywhere. I'm kind of frustrated, I want to use the name for an open source ruby based build system. I don't really feel it's appropriate for a commercial company to sit on a name for 2 years without doing anything and tying up valuable community namespace. If every company did this it would be a big problem.

While username prefixing is pretty ugly for "global" gems, it's ideal for gems for which multiple users might fork the original source code or want to have multiple different gems with the same "name". I mean, what other reasonable options are there? I'd be happy to release my gem using a prefix actually, but I'd rather do that if RubyGems.org actually understood the prefix and displayed the titles correctly - e.g. I don't believe the username prefix should be part of the gem name, but some how an explicit prefix. I guess the other problem with username prefix is that it looks pretty ugly unless it is done right. Perhaps some gems can be promoted depending on their popularity but that just ends up being the same situation again, e.g. some kind of weird contest to see who gets what name.

Thanks for your input, lets continue this discussion and figure out a good solution.

[Jonathan Rochkind]

What would be the benefits of a 'username prefixing' system of some
kind, over just informal username prefixing, like:

swilliams-build

It is, agreed. definitely not as desirable to have a gem named
'swilliams-build' compared to just 'build'; it's harder for users to
remember and more confusing to deal with.

But I think these downsides might apply just the same to any username
prefixing 'feature' implemented; and just naming your gem
'swilliams-build' is something you can do now, without the need for
development of a rubygems feature for username prefixing.

I may be wrong, this is partly just playing devil's advocate to draw out
any actual advantages there might be to an actual username prefixing
feature. (Although to be clear, I am not a rubygems.org developer, even
if a username prefixing feature might be advantageous, it still might
not fit in the roadmap priorities).

> <mailto:ni...@quaran.to>> wrote:
>
> Is there a specific name you had trouble getting? And yes, this is
> the problem with one namespace, but it's been the same problem for
> as long as RubyGems has existed. I think we should talk about this
> going forward though. It's going to be an ongoing issue.
>
> Something I strongly believe in: it doesn't matter what the name is,
> if the code is great, people will use it. I mean seriously, most
> Rails apps out there run on Unicorns and Rainbows. :)
>
> Nick
>
>
> On Tue, Apr 29, 2014 at 9:16 PM, Tyler Knappe
> <Tyler....@colorado.edu <mailto:Tyler....@colorado.edu>> wrote:
>
> There has been quite a bit of discussion about prefixing gems in
> some unique way. However, I don't think username prefixing is
> encouraged:
>
> https://groups.google.com/d/msg/rubygems-org/Z7V63f_KUXU/p248WmNFa3MJ
>
> What is the driver? What gem name were you looking for but
> found was taken? There are known spam accounts, some holding
> hundreds of names. It is possible that one of the gem names
> you're looking to use is owned by one of these accounts. If
> that is the case, I'm sure that the name can be freed up.
>
>
>
>
> On Tue, Apr 29, 2014 at 6:33 PM, Samuel Williams
> <space.ship...@gmail.com

> <mailto:space.ship...@gmail.com>> wrote:
>
> Good names for gems on RubyGems.org are becoming
> increasingly hard to figure out.
>
> Hosting a private gem server is one option, but has anyone
> considered whether per-user prefixing is still a good idea?
>
> e.g.
>
> gem "username/gemname"
> gem "username-gemname"
>
> or
>
> gem "https://gemserver/gemname"
>
> Rather than proposing a solution to this problem, I'm just
> wondering if anyone else is thinking about these issues and
> had any ideas.
>
> Kind regards
> Samuel
>
> --
> You received this message because you are subscribed to the

> Google Groups "rubygems.org <http://rubygems.org>" group.

> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> rubygems-org...@googlegroups.com

> <mailto:rubygems-org...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the

> Google Groups "rubygems.org <http://rubygems.org>" group.

> To unsubscribe from this group and stop receiving emails from
> it, send an email to rubygems-org...@googlegroups.com

> <mailto:rubygems-org...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google

> Groups "rubygems.org <http://rubygems.org>" group.

> To unsubscribe from this group and stop receiving emails from it,
> send an email to rubygems-org...@googlegroups.com

> <mailto:rubygems-org...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "rubygems.org" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to rubygems-org...@googlegroups.com

> <mailto:rubygems-org...@googlegroups.com>.

[Philippe Lafoucrière]

Go has already something similar, when "packages" are available only via a unique URL (ie: "github.com/fsouza/go-dockerclient"). Bower has also something similar.

The only drawback, is when a user delegates the gem maintenance to someone else, the gem name would change in this change (ie: defunkt-resque would become resque-resque :)).

-- 

Philippe Lafoucrière - CEO

http://www.tech-angels.com

main : +33 (0) 970 444 643

mobile : +33 (0) 6 72 63 75 40

fax : +33 (0) 9 72 12 78 75

    <Tyler....@colorado.edu <mailto:Tyler.Knappe@colorado.edu>> wrote:

        There has been quite a bit of discussion about prefixing gems in
        some unique way.  However, I don't think username prefixing is
        encouraged:

        https://groups.google.com/d/msg/rubygems-org/Z7V63f_KUXU/p248WmNFa3MJ

        What is the driver?  What gem name were you looking for but
        found was taken?  There are known spam accounts, some holding
        hundreds of names.  It is possible that one of the gem names
        you're looking to use is owned by one of these accounts.  If
        that is the case, I'm sure that the name can be freed up.




        On Tue, Apr 29, 2014 at 6:33 PM, Samuel Williams

        <space.ship.traveller@gmail.com

        <mailto:space.ship.traveller@gmail.com>> wrote:

            Good names for gems on RubyGems.org are becoming
            increasingly hard to figure out.

            Hosting a private gem server is one option, but has anyone
            considered whether per-user prefixing is still a good idea?

            e.g.

            gem "username/gemname"
            gem "username-gemname"

            or

            gem "https://gemserver/gemname"

            Rather than proposing a solution to this problem, I'm just
            wondering if anyone else is thinking about these issues and
            had any ideas.

            Kind regards
            Samuel

            --
            You received this message because you are subscribed to the
            Google Groups "rubygems.org <http://rubygems.org>" group.
            To unsubscribe from this group and stop receiving emails
            from it, send an email to

            rubygems-org+unsubscribe@googlegroups.com
            <mailto:rubygems-org+unsub...@googlegroups.com>.

            For more options, visit https://groups.google.com/d/optout.


        --
        You received this message because you are subscribed to the
        Google Groups "rubygems.org <http://rubygems.org>" group.
        To unsubscribe from this group and stop receiving emails from

        it, send an email to rubygems-org+unsubscribe@googlegroups.com
        <mailto:rubygems-org+unsub...@googlegroups.com>.

        For more options, visit https://groups.google.com/d/optout.


    --
    You received this message because you are subscribed to the Google
    Groups "rubygems.org <http://rubygems.org>" group.
    To unsubscribe from this group and stop receiving emails from it,

    send an email to rubygems-org+unsubscribe@googlegroups.com
    <mailto:rubygems-org+unsub...@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "rubygems.org" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to rubygems-org+unsubscribe@googlegroups.com
<mailto:rubygems-org+unsub...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "rubygems.org" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org+unsubscribe@googlegroups.com.

[Samuel Williams]

Could uses set up some kind of forwarding, e.g. 3xx redirect for gems which they've passed to other users?

To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org...@googlegroups.com.

[Jonathan Rochkind]

> Could uses set up some kind of forwarding, e.g. 3xx redirect for gems which they've passed to other users?

In the current system, an owner just needs to assign ownership of the gem in rubygems.org to a new owner. If it's moved to a new repo, the owner can update the homepage and/or repo fields in the gemspec/rubygems (with or without an owner change). 

Either way, no disruption to actual users of the gem, who just keep expressing their dependency on 'widget', with no need for some 3xx forwarding system. 

So, sure, all kinds of things are possible, but it doens't seem to clear to me what some kind of official 'user namespacing' system gets you.  To the extent that it gets you jrochkind/widget not conflicting with swilliams/widget, you can already choose to name your gem 'swilliams-widget' if you want, although it'll look funny. 

Users of bundler can already choose to load directly from github.com/swilliams/widget if they want to (mirroring what perhaps is common in Go, Philip says?), and github even has a 3xx forwarding system in place where you can transfer repos to other owners/teams. 

I'm pretty sure regardless of our arguments, the actual people doing the rubygems development work don't see any significant advantage to the complexity introduced by an official (mandatory?) owner-name namespacing system and won't be implementing it, but at any rate that's my (non-rubygems-developer) analysis!  In general, I'd agree that the previous github-hosted system of owner-name namespacing of gems was a mess, and sometimes broke my dependency tree in ways that required me to hunt down and figure out, and I was glad to see it go. 

Jonathan

---

From: rubyge...@googlegroups.com [rubyge...@googlegroups.com] on behalf of Samuel Williams [space.ship...@gmail.com]
Sent: Thursday, May 15, 2014 4:57 PM
To: rubyge...@googlegroups.com
Subject: Re: [rubygems.org] Good gem names are becoming increasingly rare.

[Samuel Williams]

What I imagined is that if there are a single gem from a single user, e.g.

swilliams-build

then when you run

gem install build

it would install that one.

If there was ambiguity, it would ask you to resolve this by explicitly choosing, e.g.

$ gem install build

1) swilliams-build

2) foobar-build

Please choose the one you wanted: 

I guess no solution is going to be ideal but even simple and good github usernames are hard to come by now too.

[Jonathan Rochkind]

`gem install` system needs to work without interactivity, it's often
done as part of a batch process that needs to work without human
intervention (eg capistrano -> bundle install).

Jonathan

On 5/15/14 9:09 PM, Samuel Williams wrote:
> What I imagined is that if there are a single gem from a single user, e.g.
>
> swilliams-build
>
> then when you run
>
> gem install build
>
> it would install that one.
>
> If there was ambiguity, it would ask you to resolve this by explicitly
> choosing, e.g.
>
> $ gem install build
>
> 1) swilliams-build
> 2) foobar-build
>
> Please choose the one you wanted:
>
> I guess no solution is going to be ideal but even simple and good github
> usernames are hard to come by now too.
>
>
> On 16 May 2014 10:41, Jonathan Rochkind <roch...@jhu.edu

> <mailto:roch...@jhu.edu>> wrote:
>
> > Could uses set up some kind of forwarding, e.g. 3xx redirect for
> gems which they've passed to other users?
>
> In the current system, an owner just needs to assign ownership of

> the gem in rubygems.org <http://rubygems.org> to a new owner. If

> it's moved to a new repo, the owner can update the homepage and/or
> repo fields in the gemspec/rubygems (with or without an owner change).
>
> Either way, no disruption to actual users of the gem, who just keep
> expressing their dependency on 'widget', with no need for some 3xx
> forwarding system.
>
> So, sure, all kinds of things are possible, but it doens't seem to
> clear to me what some kind of official 'user namespacing' system
> gets you. To the extent that it gets you jrochkind/widget not
> conflicting with swilliams/widget, you can already choose to name
> your gem 'swilliams-widget' if you want, although it'll look funny.
>
> Users of bundler can already choose to load directly from

> github.com/swilliams/widget <http://github.com/swilliams/widget> if

> they want to (mirroring what perhaps is common in Go, Philip says?),
> and github even has a 3xx forwarding system in place where you can
> transfer repos to other owners/teams.
>
> I'm pretty sure regardless of our arguments, the actual people doing
> the rubygems development work don't see any significant advantage to
> the complexity introduced by an official (mandatory?) owner-name
> namespacing system and won't be implementing it, but at any rate
> that's my (non-rubygems-developer) analysis! In general, I'd agree
> that the previous github-hosted system of owner-name namespacing of
> gems was a mess, and sometimes broke my dependency tree in ways that
> required me to hunt down and figure out, and I was glad to see it go.
>
> Jonathan

> ------------------------------------------------------------------------
> *From:* rubyge...@googlegroups.com
> <mailto:rubyge...@googlegroups.com>
> [rubyge...@googlegroups.com
> <mailto:rubyge...@googlegroups.com>] on behalf of Samuel Williams
> [space.ship...@gmail.com <mailto:space.ship...@gmail.com>]
> *Sent:* Thursday, May 15, 2014 4:57 PM
> *To:* rubyge...@googlegroups.com
> <mailto:rubyge...@googlegroups.com>
> *Subject:* Re: [rubygems.org <http://rubygems.org>] Good gem names

> are becoming increasingly rare.
>
> Could uses set up some kind of forwarding, e.g. 3xx redirect for
> gems which they've passed to other users?
>
>
> On 16 May 2014 02:15, Philippe Lafoucrière
> <philippe.l...@tech-angels.com

> <mailto:philippe.l...@tech-angels.com>> wrote:
>
> Go has already something similar, when "packages" are available
> only via a unique URL (ie: "github.com/fsouza/go-dockerclient

> <http://github.com/fsouza/go-dockerclient>"). Bower has also

> something similar.
> The only drawback, is when a user delegates the gem maintenance
> to someone else, the gem name would change in this change (ie:
> defunkt-resque would become resque-resque :)).
>
>
> --
> Philippe Lafoucrière - CEO
> http://www.tech-angels.com

> main : +33 (0) 970 444 643 <tel:%2B33%20%280%29%20970%20444%20643>

> mobile : +33 (0) 6 72 63 75 40

> <tel:%2B33%20%280%29%206%2072%2063%2075%2040>

> fax : +33 (0) 9 72 12 78 75

> <tel:%2B33%20%280%29%209%2072%2012%2078%2075>

>
>
>
> On Thu, May 15, 2014 at 4:12 PM, Jonathan Rochkind
> <roch...@jhu.edu <mailto:roch...@jhu.edu>> wrote:
>
> What would be the benefits of a 'username prefixing' system
> of some kind, over just informal username prefixing, like:
>
> swilliams-build
>
> It is, agreed. definitely not as desirable to have a gem
> named 'swilliams-build' compared to just 'build'; it's
> harder for users to remember and more confusing to deal with.
>
> But I think these downsides might apply just the same to any
> username prefixing 'feature' implemented; and just naming
> your gem 'swilliams-build' is something you can do now,
> without the need for development of a rubygems feature for
> username prefixing.
>
> I may be wrong, this is partly just playing devil's advocate
> to draw out any actual advantages there might be to an
> actual username prefixing feature. (Although to be clear, I

> am not a rubygems.org <http://rubygems.org> developer, even

> <mailto:ni...@quaran.to <mailto:ni...@quaran.to>>> wrote:
>
> Is there a specific name you had trouble getting?
> And yes, this is
> the problem with one namespace, but it's been the
> same problem for
> as long as RubyGems has existed. I think we should
> talk about this
> going forward though. It's going to be an ongoing
> issue.
>
> Something I strongly believe in: it doesn't matter
> what the name is,
> if the code is great, people will use it. I mean
> seriously, most
> Rails apps out there run on Unicorns and Rainbows. :)
>
> Nick
>
>
> On Tue, Apr 29, 2014 at 9:16 PM, Tyler Knappe
> <Tyler....@colorado.edu

> <mailto:Tyler....@colorado.edu>
> <mailto:Tyler.Knappe@colorado.__edu

> <mailto:Tyler....@colorado.edu>>> wrote:
>
> There has been quite a bit of discussion about
> prefixing gems in
> some unique way. However, I don't think
> username prefixing is
> encouraged:
>

> https://groups.google.com/d/__msg/rubygems-org/Z7V63f_KUXU/__p248WmNFa3MJ

> <https://groups.google.com/d/msg/rubygems-org/Z7V63f_KUXU/p248WmNFa3MJ>
>
> What is the driver? What gem name were you
> looking for but
> found was taken? There are known spam
> accounts, some holding
> hundreds of names. It is possible that one of
> the gem names
> you're looking to use is owned by one of these
> accounts. If
> that is the case, I'm sure that the name can be
> freed up.
>
>
>
>
> On Tue, Apr 29, 2014 at 6:33 PM, Samuel Williams

> <space.ship.traveller@gmail.__com
> <mailto:space.ship...@gmail.com>
> <mailto:space.ship.traveller@__gmail.com

> <mailto:space.ship...@gmail.com>>> wrote:
>
> Good names for gems on RubyGems.org are
> becoming
> increasingly hard to figure out.
>
> Hosting a private gem server is one option,
> but has anyone
> considered whether per-user prefixing is
> still a good idea?
>
> e.g.
>
> gem "username/gemname"
> gem "username-gemname"
>
> or
>
> gem "https://gemserver/gemname"
>
> Rather than proposing a solution to this
> problem, I'm just
> wondering if anyone else is thinking about
> these issues and
> had any ideas.
>
> Kind regards
> Samuel
>
> --
> You received this message because you are
> subscribed to the
> Google Groups "rubygems.org

> <http://rubygems.org> <http://rubygems.org>" group.

> To unsubscribe from this group and stop
> receiving emails
> from it, send an email to

> rubygems-org+unsubscribe@__googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>
>
> <mailto:rubygems-org+...@googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>>.
> For more options, visit
> https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are
> subscribed to the
> Google Groups "rubygems.org

> <http://rubygems.org> <http://rubygems.org>" group.

> To unsubscribe from this group and stop
> receiving emails from
> it, send an email to

> rubygems-org+unsubscribe@__googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>
>
> <mailto:rubygems-org+...@googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>>.
> For more options, visit
> https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are
> subscribed to the Google
> Groups "rubygems.org <http://rubygems.org>
> <http://rubygems.org>" group.
> To unsubscribe from this group and stop receiving
> emails from it,
> send an email to

> rubygems-org+unsubscribe@__googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>
> <mailto:rubygems-org+...@googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>>.
> For more options, visit
> https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to
> the Google
> Groups "rubygems.org <http://rubygems.org>" group.
> To unsubscribe from this group and stop receiving emails
> from it, send

> an email to rubygems-org+unsubscribe@__googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>
> <mailto:rubygems-org+...@googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>>.
> For more options, visit
> https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the
> Google Groups "rubygems.org <http://rubygems.org>" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to

> rubygems-org+unsubscribe@__googlegroups.com
> <mailto:rubygems-org%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the
> Google Groups "rubygems.org <http://rubygems.org>" group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to rubygems-org...@googlegroups.com
> <mailto:rubygems-org...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "rubygems.org <http://rubygems.org>" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to rubygems-org...@googlegroups.com
> <mailto:rubygems-org...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "rubygems.org <http://rubygems.org>" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to rubygems-org...@googlegroups.com
> <mailto:rubygems-org...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "rubygems.org" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to rubygems-org...@googlegroups.com
> <mailto:rubygems-org...@googlegroups.com>.

[Samuel Williams]

Okay, as an alternative, allow people to release gems under the same name, but if they are not the owner the gem version is postfixed with their name, e.g.

build-0.0.0

build-0.0.0-swilliams

The versioning spec would then be responsible for selecting the correct variant to install, e.g.

gem "build", "~> 0.0.0-swilliams"

# would install "build-0.0.x-swilliams"

or

gem "build", "~> 0.0.0"

# would install "build-0.0.x"

The "-swilliams" tag would be required and explicit for a specific gem variant.

This would allow gems where the original author has sort of "given up" or "gone away" to be maintained by the community without breaking backwards compatibility and without polluting the namespace.

Using an explicit variant name, e.g. "imagemagic-x.y.z-hdri" could be great when gems (such as in this example) haven't been updated to track changes in the original C library - lots of people are complaining about this gem but no updates have been forthcoming.

Would something like this work?

    <mailto:rubygems-org@googlegroups.com>
    [rubyge...@googlegroups.com
    <mailto:rubygems-org@googlegroups.com>] on behalf of Samuel Williams
    [space.ship.traveller@gmail.com <mailto:space.ship.traveller@gmail.com>]

    *Sent:* Thursday, May 15, 2014 4:57 PM
    *To:* rubyge...@googlegroups.com

    <mailto:rubygems-org@googlegroups.com>

    *Subject:* Re: [rubygems.org <http://rubygems.org>] Good gem names

    are becoming increasingly rare.

    Could uses set up some kind of forwarding, e.g. 3xx redirect for
    gems which they've passed to other users?


    On 16 May 2014 02:15, Philippe Lafoucrière

    <philippe.lafoucriere@tech-angels.com

                <mailto:Tyler.Knappe@colorado.edu>

                <mailto:Tyler.Knappe@colorado.__edu

                <mailto:Tyler.Knappe@colorado.edu>>> wrote:

                         There has been quite a bit of discussion about
                prefixing gems in
                         some unique way.  However, I don't think
                username prefixing is
                         encouraged:

                https://groups.google.com/d/__msg/rubygems-org/Z7V63f_KUXU/__p248WmNFa3MJ

                <https://groups.google.com/d/msg/rubygems-org/Z7V63f_KUXU/p248WmNFa3MJ>

                         What is the driver?  What gem name were you
                looking for but
                         found was taken?  There are known spam
                accounts, some holding
                         hundreds of names.  It is possible that one of
                the gem names
                         you're looking to use is owned by one of these
                accounts.  If
                         that is the case, I'm sure that the name can be
                freed up.




                         On Tue, Apr 29, 2014 at 6:33 PM, Samuel Williams

                         <space.ship.traveller@gmail.__com

                <mailto:space.ship.traveller@gmail.com>
                         <mailto:space.ship.traveller@__gmail.com

                <mailto:rubygems-org+__unsub...@googlegroups.com

                <mailto:rubygems-org%2Bunsu...@googlegroups.com>>.
                             For more options, visit
                https://groups.google.com/d/__optout
                <https://groups.google.com/d/optout>.

                         --
                         You received this message because you are
                subscribed to the
                         Google Groups "rubygems.org

                <http://rubygems.org> <http://rubygems.org>" group.

                         To unsubscribe from this group and stop
                receiving emails from
                         it, send an email to

                rubygems-org+unsubscribe@__googlegroups.com
                <mailto:rubygems-org%2Bunsu...@googlegroups.com>

                <mailto:rubygems-org+__unsub...@googlegroups.com

                <mailto:rubygems-org%2Bunsu...@googlegroups.com>>.
                         For more options, visit
                https://groups.google.com/d/__optout
                <https://groups.google.com/d/optout>.

                     --
                     You received this message because you are
                subscribed to the Google
                     Groups "rubygems.org <http://rubygems.org>
                <http://rubygems.org>" group.
                     To unsubscribe from this group and stop receiving
                emails from it,
                     send an email to

                rubygems-org+unsubscribe@__googlegroups.com
                <mailto:rubygems-org%2Bunsu...@googlegroups.com>

                     <mailto:rubygems-org+__unsub...@googlegroups.com

                <mailto:rubygems-org%2Bunsu...@googlegroups.com>>.
                     For more options, visit
                https://groups.google.com/d/__optout
                <https://groups.google.com/d/optout>.

                --
                You received this message because you are subscribed to
                the Google
                Groups "rubygems.org <http://rubygems.org>" group.
                To unsubscribe from this group and stop receiving emails
                from it, send

                an email to rubygems-org+unsubscribe@__googlegroups.com
                <mailto:rubygems-org%2Bunsu...@googlegroups.com>

                <mailto:rubygems-org+__unsub...@googlegroups.com

                <mailto:rubygems-org%2Bunsu...@googlegroups.com>>.
                For more options, visit
                https://groups.google.com/d/__optout
                <https://groups.google.com/d/optout>.

            --
            You received this message because you are subscribed to the
            Google Groups "rubygems.org <http://rubygems.org>" group.
            To unsubscribe from this group and stop receiving emails
            from it, send an email to

            rubygems-org+unsubscribe@__googlegroups.com
            <mailto:rubygems-org%2Bunsu...@googlegroups.com>.
            For more options, visit https://groups.google.com/d/__optout
            <https://groups.google.com/d/optout>.

        --
        You received this message because you are subscribed to the
        Google Groups "rubygems.org <http://rubygems.org>" group.
        To unsubscribe from this group and stop receiving emails from

        it, send an email to rubygems-org+unsubscribe@googlegroups.com
        <mailto:rubygems-org+unsub...@googlegroups.com>.

        For more options, visit https://groups.google.com/d/optout.


    --
    You received this message because you are subscribed to the Google
    Groups "rubygems.org <http://rubygems.org>" group.
    To unsubscribe from this group and stop receiving emails from it,

    send an email to rubygems-org+unsubscribe@googlegroups.com
    <mailto:rubygems-org+unsub...@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to the Google
    Groups "rubygems.org <http://rubygems.org>" group.
    To unsubscribe from this group and stop receiving emails from it,

    send an email to rubygems-org+unsubscribe@googlegroups.com
    <mailto:rubygems-org+unsub...@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google
Groups "rubygems.org" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to rubygems-org+unsubscribe@googlegroups.com
<mailto:rubygems-org+unsub...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "rubygems.org" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubygems-org+unsubscribe@googlegroups.com.

[Samuel Williams]

Another example of a gem causing problems is the mail gem - hasn't been updated for over a year and now it's causing problems because it's dependency on mime-types hasn't been updated. All the tests pass, people have submitted patches, etc, but nothings happened. The only option right now is for someone to fork it, release it under a new name, and for everyone to find that new gem somehow. Could be great of someone could fork it and release it under the same name on ruby gems, even with some explicit postfix required.

[Benjamin Fleischer]

the mail gem being abandoned has nothing to do with gem name scarcity. that's just maintainership. not saying it's not a problem.. hasn't anyone asked the owner for gem push rights? if you have gem push, you don't need the original repo at all.

[Samuel Williams]

Benjamin, I guess in some ways it isn't directly related, but to me I do see it as being related because it is to do with naming and I believe it is in the communities best interest that a good solution to these types of problems is found. The ability for someone to release a gem under a given name is a very powerful privilege, but with power comes responsibility, which as we can see in a number of different situations such responsibility is not always forthcoming.

I believe that Ruby needs to have excellent high quality code that is easily accessible to new users. Names like "mail", I feel, need to point at relevant working code (for some reasonable definition). If people using these names are increasingly lacking in attention, the general quality of the entire Ruby ecosystem is dragged down.

The main problem I have is that it is impossible for well-meaning developers to contribute to gems whose authors are unresponsive or uninterested. In these cases, it isn't usually possible to acquire "gem push rights" for a given name, despite the best intentions. This often manifests in important projects (such as those mentioned earlier), you see hundreds of backed up tickets, pull requests, and the likes, and no way for anyone to actually improve the quality of the code.

After thinking it through, I've come to the conclusion that it isn't unreasonable for any Ruby developer to push to any gem name. The versioning system should take care of the details of whose gem you actually end up installing. As suggested, and what I think is the best option, is for the first user for a specific name to get the ability to push to non-"branch" identifiers as is currently standard, e.g. "mail-1.0.0". If I decided to fork mail and fix the outstanding issues, I could release it as "mail-1.0.0-swilliams" or some other postfix specific to my username.

Users could still write

gem "mail"

They would get exactly the behaviour as present as if no user specific versions were available, but if they saw the fixed release, they could write

gem "mail", "~> 1.0.0-swilliams"

...and get the forked version. I believe all users should have this right for all gems, it seems like the only logical model for a distributed environment where lots of people are working on lots of different projects.

The alternative which I think is a poor substitute, is that people explicitly name their gems with different names. e.g. I could release my gem as "mail2" or "swilliams-mail" and another user could release "mail3" or "bob-mail". This, I feel, harms the community significantly as it doesn't help new users figure out what gems are actually forks/bugfixes or which things are entirely different, and it establishes a poor community contract for gem releases (i.e. a massive glut of new names without any real benefit).

Whether or not it would be reasonable to show the forked releases on the gem page or not is another point, but ultimately I think tying the power of one developer to a specific name is holding back the community, and that the benefits of finding some solution to this problem would be massive in terms of keeping code up to date and relevant. Many projects are in an unfortunate state of decay and users can do little to help or change that. Right now, the power to release is in the hands of the few, and the ability for people to contribute in a meaningful way is limited.

Kind regards,

Samuel

[Benjamin Fleischer]

On Sunday, May 25, 2014 1:00:45 AM UTC-5, Samuel Williams wrote:

If I decided to fork mail and fix the outstanding issues, I could release it as "mail-1.0.0-swilliams" or some other postfix specific to my username.

Users could still write

gem "mail"

They would get exactly the behaviour as present as if no user specific versions were available, but if they saw the fixed release, they could write

gem "mail", "~> 1.0.0-swilliams"

...and get the forked version.

So, FWIW, I took this conversation to the codes and wrote a PR for the mail gem since I didn't think any of the existing ones were being attended to by the maintainer and had some room for improvements, e.g. tests. https://github.com/mikel/mail/pull/713

This issue of maintaintership is more related to the discussion thread on a rubygem adoption center https://groups.google.com/d/topic/rubygems-org/niS5ZO9DNgk/discussion

The specific example above, I think, is unnecessary and unnecessarily complex.

When GitHub was building gems from repos, we would install the mocha gem as jferris-mocha because github did some sleight of hand, and took the name from the gemspec, 'mocha', and when building the gem, changed the name to 'jferris-mocha' by preppending the author's github username.  see https://github.com/jferris/mocha/blob/2fb62bdae9c8f3527e64f69ed71bfd8c5296ab0b/mocha.gemspec#L4 and https://rubygems.org/gems/jferris-mocha

That was not a state of nature that was desirable, which is part of why rubygems.org aka gemcutter was created.  We used to specify multiple gem sources, and now only really use one.

The gemspec has a name field.  If you ran `bundle gem mocha` you could build and install that, but it's wouldn't have any of the code in it from the real mocha gem. Things fall apart; the center cannot hold.  The principle of least surprise is violated.  

RubyGems.org is decoupled from GitHub. It doesn't know or care about source control.  It is a place to publish and download gems.  There's an ongoing discussion to require lower-cased gem names. Until that day, though, you can publish 'mail', 'Mail', MAIL' etc.  Isn't that confusing? A real example:  https://rubygems.org/gems/Saikuro and https://rubygems.org/gems/saikuro

I don't think that's a good thing. It has certainly caused me pain.

Now, what's wrong with publishing 'mail-swilliams'? That's was I did with metric_fu until I became maintainer. I pushed bf4-metric_fu and added an issue. I did similarly with acts-as-taggable-on (creating acts_as_taggable_on).  That's not to say gem squatting isn't a problem, or that abandoned gems aren't a problem, just that it does not make an argument for letting anybody publish to a given gem name at any time.

Now, if we were to do 'gem install mail -v "~> 1.0.0-swilliams"' that's certainly possible, as long as you have push rights on rubygems.org for the mail gem.  Otherwise, doing so would require a gigantic rewrite of rubygems and rubygems.org to change the meaning of version to version(-forkname).

/dems my thoughts

[Samuel Williams]

Ben, thanks for all your hard work on the PR and your thoughts.

I'm well aware of the GitHub situation, I used to use it and it was cumbersome, but it did allow people to fork gems and have them available in a way that was systematic and expected.

> Now, what's wrong with publishing 'mail-swilliams'? That's was I did with metric_fu until I became maintainer. I pushed bf4-metric_fu and added an issue. I did similarly with acts-as-taggable-on (creating acts_as_taggable_on).  That's not to say gem squatting isn't a problem, or that abandoned gems aren't a problem, just that it does not make an argument for letting anybody publish to a given gem name at any time.

I actually don't have a problem with this but (a) I feel it is probably confusing for new users where the "mail" gem is broken but "mail-someusername" is working fine. It is a good solution for the current implementation of RubyGems but I'm not sure if it is desirable for the community at large. Finally, if/once the original gem is fixed, the "mail-someusername"  gem becomes largely useless and IMHO, increases the amount of junk on RubyGems.org. 

> Now, if we were to do 'gem install mail -v "~> 1.0.0-swilliams"' that's certainly possible, as long as you have push rights on rubygems.org for the mail gem.  Otherwise, doing so would require a gigantic rewrite of rubygems and rubygems.org to change the meaning of version to version(-forkname).

Yes this is the core of my proposal, adding support for explicit forks/branches, allowing all users to push to all gem names, but only with an explicitly named version fork/branch if they are not a maintainer for the gem.

I'm happy to discuss this further but only if it is a useful thing to discuss - time is better spent for everyone on productive tasks, but I do feel this is an important issue for the community which needs to be resolve, either through an "adoption" center, or some kind of technical solution like the one I'm suggesting. I certainly believe the value of my proposal, but there could certainly be downsides which I haven't identified.

Thanks for your time.

[Samuel Williams]

Oh, (b) doesn't allow the author of the fork to leverage the value of the existing name, which in turn makes it harder for users to find the forked/fixed/updated version of the gem. A gem e.g. "acts-as-taggable-on" and "acts_as_taggable_on" might be similar, or they might be completely different - hard to tell, the name suggests they should be similar but this isn't always the case, especially over time they may diverge significantly.

[Jonathan Rochkind]

On 5/26/14 6:47 PM, Benjamin Fleischer wrote:
> If I decided to fork mail and fix the outstanding issues, I could
> release it as "mail-1.0.0-swilliams" or some other postfix specific
> to my username.
>
> Users could still write
>
> gem "mail"
>
> They would get exactly the behaviour as present as if no user
> specific versions were available, but if they saw the fixed release,
> they could write
>
> gem "mail", "~> 1.0.0-swilliams"
>
> ...and get the forked version.

So, right now, without any code changes or additional features, you
could simply release a gem named "mail-swilliams", and the behavior
would be the same, except they'd have to write:

gem "mail-swilliams", "~> 1.0.0".

I am not a rubygems developer/maintainer, but I'd imagine the
maintainers would think about how much benefit to what use cases would
accrue from the feature addition compared to status quo, when feature
additions carry risks of bugs and unintended side effects and
interactions with other parts of rubygems.

Jonathan