Advice for sharing configs across many projects

[cmschuetz]

Hi Samuel,

Big fan of async and use it daily, thanks for all that you do.

I'm in a situation with lots of ruby projects and want to share a default set of trace configurations (e.g. with a specific backend and set of providers) and make it as easy as possible to share, update, etc. In other words, install this gem and you're good to go.

I've found that encapsulating these configs within a gem is challenging because of load order. If I can ensure this setup logic runs before traces is loaded, everything works great, but if another gem loads traces first, I can't find a good way to perform this setup and "reload" everything without some hack-adjacent code.

Concretely, if the backend isn't configured before this piece runs:

if self.enabled?
	# Extend the specified class in order to emit traces.
	def self.Provider(klass, &block)
		klass.extend(Singleton)
		provider = klass.traces_provider
		klass.prepend(provider)
		
		provider.module_exec(&block) if block_given?
		
		return provider
	end
else
	def self.Provider(klass, &block)
		# Tracing disabled.
	end
end

I can't find a good way of loading providers without reloading the module.

Curious to hear how you've seen this done and if I'm completely thinking about this the wrong way

[ioquatix]

Some types of libraries are extremely tricky due to their extensibility and load timing requirements. Console is another one since it has configurable outputs, and those outputs need to be loaded when Console is first used, but what if during loading, someone tries to log?

The traces gem has similar issues as you've found out. Trace providers must be loaded after the provider is ready, and if no trace provider is loaded, they must be no-ops.

The guarantees are:

• In config/traces.rb in def prepare you are guaranteed to be invoked after the provider is ready but before tracing starts. This is where you should load all your trace providers: https://github.com/socketry/async/blob/main/config/traces.rb
• In gems, you can expose your own trace providers, e.g. my_gem/lib/traces/provider/my_class.rb and you can create easy to use amalgamations like my_gem/lib/traces/provider/my_gem.rb which require all the other trace providers in your library.

Part of the reason for doing it this way is to ensure the library is zero cost if you don't have tracing enabled, and as a consequence the end user must opt into tracing rather than having it load by default (at least according to the current design).

Does that answer your question?

[cmschuetz]

Yes it does thank you, that makes sense.

My only follow-up is if you have advice for embedding the backend within this shared-gem as I'm trying to avoid having to set TRACES_BACKEND in every repository. I can of course work around this in-code, but if traces happens to be loaded before this shared gem I don't think there's a good way to retroactively apply the backend.