Opentelemetry-go: RFC to rename global package

Created on 31 Jul 2020  路  6Comments  路  Source: open-telemetry/opentelemetry-go

From recent feedback and from existing understanding, it is recognized that global is not an ideal package name.

Names such as kv, global and standard can easily overlap with other packages in the language ecosystem.
Consider giving them more unique names to improve developer productivity. Users shouldn鈥檛 stress about importing the name package by constantly checking the import paths or shouldn鈥檛 have to rename imports because of an overlap.

Based on the function of this package it seems like an appropriate package, but it would be ideal if we can brainstorm improved names.

API p1 question required-for-ga

Most helpful comment

I was refactoring some code and noticed that we've moved ErrorHandler to the root of the repository. In the sense that a "root" is global, it might make sense to put everything from the global package into the root of the repository. Then we'd read otel.SetMeterProvider() which sounds good, as opposed to global.SetMeterProvider().

I like this approach. :+1:

All 6 comments

I think global is a fine package name and I have yet to experience any conflicts with other packages.

I was refactoring some code and noticed that we've moved ErrorHandler to the root of the repository. In the sense that a "root" is global, it might make sense to put everything from the global package into the root of the repository. Then we'd read otel.SetMeterProvider() which sounds good, as opposed to global.SetMeterProvider().

I was refactoring some code and noticed that we've moved ErrorHandler to the root of the repository. In the sense that a "root" is global, it might make sense to put everything from the global package into the root of the repository. Then we'd read otel.SetMeterProvider() which sounds good, as opposed to global.SetMeterProvider().

I like this approach. :+1:

Looking at this migration our global getter functions (i.e. MeterProvider, TracerProvider, and ErrorHandler) will all clash with their types. Looking at rename options for the getters:

  1. Get*
  2. Default*, also switch setter to SetDefault*
  3. Global*, also switch setter to SetGlobal*

Leaning towards (1)

Looking at this migration our global getter functions (i.e. MeterProvider, TracerProvider, and ErrorHandler) will all clash with their types. Looking at rename options for the getters:

  1. Get*
  2. Default*, also switch setter to SetDefault*
  3. Global*, also switch setter to SetGlobal*

Leaning towards (1)

+1 for option (1).

Looking into flattening this out last week and found the initial dependency cycle that likely split the package in the first case.

https://github.com/open-telemetry/opentelemetry-go/blob/b9357d7ee2b37b475521db639f0c738f02ca8e57/api/global/internal/trace.go#L39

And also now,

https://github.com/open-telemetry/opentelemetry-go/blob/b9357d7ee2b37b475521db639f0c738f02ca8e57/api/global/internal/state.go#L25

These import cycles appear to be artifacts of the tight coupling of these packages. A good indicator that they need to be refactored, but it will require a bit more work than just moving this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MrAlias picture MrAlias  路  6Comments

johananl picture johananl  路  6Comments

kyleconroy picture kyleconroy  路  6Comments

MrAlias picture MrAlias  路  7Comments

tigrannajaryan picture tigrannajaryan  路  5Comments