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

Feature flag to error if multiple versions of sentry-core are found #661

Open
Diggsey opened this issue May 29, 2024 · 2 comments
Open

Feature flag to error if multiple versions of sentry-core are found #661

Diggsey opened this issue May 29, 2024 · 2 comments

Comments

@Diggsey
Copy link

Diggsey commented May 29, 2024

I've used sentry quite a bit, and a very common issue is that you end up with two different versions of sentry-core in your application, which results in errors being silently dropped! This issue is really hard to debug because some errors come through just fine - it just depends which crate is reporting the error.

What I have done for our latest application is add a build.rs which reads the project-wide lockfile, and raises an error if multiple versions of sentry-core are found.

I think this functionality would be great to add directly to sentry-core's build script, enabled behind a feature flag, and for use of this feature flag to be recommended to application authors in the documentation.

@Swatinem
Copy link
Member

Thanks for the feedback and the idea.

Indeed this problem comes up quite often, and I believe one reason is that sentry is split up into multiple crates, which in hindsight was not the best idea as it makes a ton of stuff more complicated than it needs to be.

The idea with using a build.rs script is interesting. I’m not sure it would work though, as I believe cargo tries very hard to sandbox each crate, and I don’t think access to a project-wide Cargo.lock is readily available.

However, this reminds me that there are quite some solutions in the ecosystem that promote better lockfile and dependency hygiene. It may be worth investigating if we can add sentry/-core to any builtin deny-list, so users using such cargo tools will automatically get this flagged.

@Diggsey
Copy link
Author

Diggsey commented May 29, 2024

I believe cargo tries very hard to sandbox each crate, and I don’t think access to a project-wide Cargo.lock is readily available.

I just use the project_root crate:

use std::process;

use cargo_lock::Lockfile;

fn main() {
    let project_root = project_root::get_project_root().expect("Failed to get project root");
    let lockfile =
        Lockfile::load(project_root.join("Cargo.lock")).expect("Failed to read lock file");
    let sentry_versions: Vec<_> = lockfile
        .packages
        .iter()
        .filter(|pkg| pkg.name.as_str() == "sentry-core")
        .collect();
    if sentry_versions.len() > 1 {
        println!("Error: Multiple versions of sentry-core found in lockfile:");
        for sentry_version in sentry_versions {
            println!("{}: {}", sentry_version.name, sentry_version.version);
        }
        process::exit(1);
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants