Jared White (ResistanceNet ✊)

Long term…

If the "only" thing which comes out of the #Ruby Central debacle is we end up with officially decentralized gem hosting along with namespace support at the package level,

that's actually a huge win.

But I'm positive we're going to see other innovations.

It's a lie that growth only comes from top-down BDFL-style orgs. Not only that, it's often the opposite. Innovation comes from—oh yeah, here we go—diversity.

Ever heard of Loose Coupling? Works for culture not just codebases.

Oct 11 at 1:44amWeb
Show threadPointlessOne Oct 11

@jaredwhite
> decentralized gem hosting along with namespace support at the package level

We already have it. Host your own small index. Gems are namespaced to `source`.

Show threadRŌBÆRTOct 11
@pointlessone
That’s not entirely accurate, at least regardless to what I think @jaredwhite ment with namespaces.
Say you have two sources A and B and a gem named G hosted on both of them. These gems might totally different. Say you have a different gems J and Y both with a dependency on G. Which do they mean, how can we use both G(A) and G(B) at the same time?
AFAIK, there’s work done to get this using Namespaces. But we don’t have it yet.
Show threadPointlessOne Oct 11

@fnordfish @jaredwhite Yeah, I see what you're saying but until we get Namespace in Ruby there’s no way to implement gem namespaces.

The main issue is that gem namespaces have to be globally unique in order to avoid collisions you described. Two sources can have same namespaces in them and gems with same names in them. That is, you still can have ns/G(A) and ns/G(B).

Sources as gem namespaces is kinda the best we can have as URLs are unique already.

Granted, this messes a bit with mirrors and caches (e.g. Artifactory) that assume only one source exists. Caching proxies are still immediately useful. Mirrors can solve this by hosting multiple sources at different URLs. E.g. gem-mirror.com/rubygems/, gem-mirror.com/gem-coop/

Show threadRŌBÆRTOct 11
@pointlessone yah. Let’s see what will happen.
But I agree with the notion, that this debacle might be just the right push we need to get this done "the right way"
Show threadJared White (ResistanceNet ✊)Oct 11
@pointlessone @fnordfish ah, I think we're getting wires crossed with the namespace concept. I'm not talking about multiple gems with the same "name", I'm talking about being able to pull multiple gems in from multiple sources without having to manually specify which gem indexes should be used for which gems. In other words, don't put the burden on the consumer to solve decentralization (already a feature), it should be on the publishers (not yet a feature).
Show threadPointlessOne Oct 11

@jaredwhite Could you show an example of an API you have in mind?

@fnordfish

Show threadJared White (ResistanceNet ✊)Oct 11

@pointlessone @fnordfish the proposals I've seen are something along the lines of

@ org1/gemA
@ org2/gemB

and the gem from org1 comes from one service and the gem from org2 comes from a different service. it would be handled by Bundler (or equivalent) automatically.

Show thread|7eter l-|. l3oling 🧰Oct 11
@jaredwhite @pointlessone @fnordfish it is a very active discussion in the Bundler slack (invite links on Bundler.io, the slack is not controlled by RubyCentral) in the #gem-coop channel. Join!
Show threadPointlessOne Oct 11

@jaredwhite I don't think this would work with gems as long as multiple sources can be specified.

This sort of namespacing can only work either with a single index (like NPM) or globally unique namespaces which is not a thing that can realistically be enforced without a central namespace registry.

Any way you turn it it's DNS all over again.

@fnordfish

Show thread|7eter l-|. l3oling 🧰Oct 14
@jaredwhite I am working on a federated gem server right now. Can’t stand the thought of continuing to push gems to RC.O.