Aggregate Class in Global Namespace

[iterion]

It seems that a dependency (aggregate) is defining a class on the global namespace (namely Aggregate). If you have a model or some other class defined as Aggregate in your project the version included by this gem may cause conflicts and lead to some confusion, especially with ruby's ability to reopen classes later.

It seems that aggregate is included by librato-metrics, so this may not be an issue that can be fixed in this repo.

[nextmat]

@iterion This is true. I don't know of a way to require a gem in ruby such that it can't import things into the global namespace. The gem in question is an important dependency so removing it isn't likely.

The same is true of our other dependencies, faraday, multi_json, etc. It is just less likely you'll reuse those names and collide with them.

Is namespacing classes in your project an option?

[iterion]

Namespacing is an option, but not really preferred (dev effort to rename > integrating with another service). Aggregate seems like it could exist in many rails projects, especially as a name for a model. I'd really like to get Librato working, but the conflict is unfortunate and means we won't be able to move forward without additional effort.

I looked around at the code to see what it would take to remove the dependency and it appears that it's only referenced by Librato::Metrics::Aggregator. Is it possible that Aggregate could be forked by librato and namespaced under Librato's namespace (Librato::Metrics::Aggregate)? I'm not sure how many other projects are using the aggregate gem so I'm not sure how responsive they would be to namespacing within that gem and I'm not even sure what a good namespace would be for it.

[radiospiel]

I would second this one (if this is still an issue.) Would this problem also appear when I am not using client side aggregates at all?