Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

near-o11y is not compilable with Rust 1.71 due to crate dependency and internal module having the same name (opentelemetry) #10477

Open
frol opened this issue Jan 22, 2024 · 3 comments
Labels
C-bug Category: This is a bug

Comments

@frol
Copy link
Collaborator

frol commented Jan 22, 2024

Describe the bug

near-o11y is not compilable with Rust before 1.72:

image

opentelemetry.workspace = true

mod opentelemetry;

There should not be the crate and internal module named the same regardless of the fact if Rust 1.72+ can handle it or not. It may confuse developers dealing with this code.

To Reproduce

Compile near-o11y with Rust 1.70.

Expected behavior

I expect the module to not raise compilation error due to the naming collision.

Version (please complete the following information):

  • near-* crates 0.20 and master branch
  • rust version: 1.70
@frol frol added the C-bug Category: This is a bug label Jan 22, 2024
@nagisa
Copy link
Collaborator

nagisa commented Jan 22, 2024

The ecosystem has generally converged to MSRV policy of N - 2 (current stable and 2 previous releases.) Anything more than that is going to be a very painful uphill battle for everybody involved, so I don’t really see any motivation for nearcore try and provide a guarantee greater than that.

The current stable rust toolchain is already up-to 1.75.0, with 1.73 being the oldest supported release within the N - 2 scheme. Although nearcore does not currently commit to supporting anything but the latest stable rust toolchain, supporting versions as old as 1.71 seems like it wouldn’t be in scope within even the N - 2 policy.

@frol
Copy link
Collaborator Author

frol commented Jan 22, 2024

@nagisa Regardless of MSRV, I would find it confusing as a contributor as it makes harder to reason about things where there is a naming collision

@nagisa
Copy link
Collaborator

nagisa commented Jan 22, 2024

I don’t disagree with that motivation, and I did not contend it :) Having a maintainable and surprise-free codebase is definitely a desirable property.

We can rename the module for sure, the current name is entirely internal to the implementation of the o11y crate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug
Projects
None yet
Development

No branches or pull requests

2 participants