Analytics

[mvastola]

Just a random yet useful idea: has there ever been any discussion about requesting some mild analytics from bundler install/bundler update invocations?

The idea would be to inform gem maintainers of:

• the demand in support for a given dependency/version/platform
• prominent configurations in use with their gems (to focus on in testing and to cater features to)

---

My use case (though for the reasons stated, I think the value of this feature extends beyond this specific case) in short:

I took over as maintainer of the attr_encrypted gem, which is widely used but has been unmaintained for a while. The activerecord gem's constraint in the .gemspec supports rails versions as early as 2.0. The TL;DR is I'm in a position where I have nothing to go on but guesswork for any version support changes I make.

(The slightly more complicated version includes the existence of a number of forks because upstream doesn't support the latest RoR versions, but also the possibility of monkeypatches, meaning I have no idea who the current audience is in terms of ruby/rails configurations pulling this gem.)

---

Anyway, to implement this, I was thinking that bundler could add a header with this information (to then be tallied by rubygems). Alternatively this it could be sent when fetching the package index. There's a decent argument I think that that would be more efficient and a better indicator of the # of live apps using the gem. Those stats wouldn't be vulnerable to sample biases due to lack of recent releases or the prevalence of users with more restrictive version constraints. The downside, of course, is that at that point we're not counting downloads, even if it is a more informative metric.

It seemed like a really useful potential feature to me, so I wanted to test the waters and see if the stars might align to make this feasible. There would be a few privacy concerns to address. I can think of * but -- at least in the fantasy in my head haha -- they seem kind of uncontroversial.

Considerations:

• The first thing is we would need to figure out if/how a user is prompted to opt-in, as well as what the defaults are if they don't.
• Beyond that, there's a security concern, so we would need to restrict Gemfile sources to only be told about gems from that same source.
• Beyond that, I can't immediately think of any privacy concerns, other than to not create a slippery slope here.
• Beyond that, the only downside I can conceive of if how this would work with rubygems.org infra/storage (which I'm guessing is donated). I obviously can't speak at all to those logistics.

I'm not sure if/how the maintainers/oversight/etc of rubygems and bundler intersect (both being maintained as part of ruby), or (let's face it) how much of a fantasy this is, but I'm curious what would be required to make this happen. And if there is any interest.

Thanks!

[simi]

Just a random yet useful idea: has there ever been any discussion about requesting some mild analytics

moved to discussions

Anyway, to implement this, I was thinking that bundler could add a header with this information (to then be tallied by rubygems).

Something similar is already happening using User-Agent header.

Some basic stats (raw data) are reachable at https://ecosystem.rubytogether.org/, I recommend to check out https://ecosystem.rubytogether.org/?unique=1 where some "deduplication" is happening. Feel free to join us at Bundler Slack in #stats channel.