Solution to "ImportError: cannot import name 'GrowthBookClient' from 'growthbook'"

If you're using version 1.2.1 of the GrowthBook Python library, you may have seen in the documentation on GitHub or PyPI that the GrowthBookClient should be imported like this:

from growthbook import GrowthBookClient

 However, this results in the following error:

api/feature_flag_service.py", line 1, in <module>

    from growthbook import GrowthBookClient, Options, UserContext

ImportError: cannot import name 'GrowthBookClient' from 'growthbook'

The fix is simple: instead of following the documentation, use the correct import path based on the actual library structure:

from growthbook.growthbook_client import GrowthBookClient 

Solution to sqlx prepare error: failed to lookup address information: Name or service not known

I was getting the error "failed to lookup address information: Name or service not known" when running the command cargo sqlx prepare. The error seemed obvious — my DATABASE_URL environment variable was probably incorrect. However, after checking everything and confirming that it was correct (ad-hoc connections were working, and even the service startup connected successfully), I figured out the issue:

My service required additional environment variables to start. Without these env vars, it wouldn't start and would return an error. It turns out that when running cargo sqlx prepare without those variables, the error gets silently swallowed, and the database connection simply fails.

After supplying the same environment variables I use for cargo run to cargo sqlx prepare, the problem was resolved.

Solution to failed to acquire username/password from local configuration on rust git libs

Let's say you need to work on a Rust project that depends on other libraries hosted in a private Git repository. This project uses the repository's HTTPS URL. For example:

your-lib = { git = "ssh://git@github.com/your-company/your-lib.git"}

Then you try to start the project and encounter the following error:

$ cargo run

    Blocking waiting for file lock on package cache

    Updating crates.io index

    Updating git repository `https://github.com/your-company/your-lib.git`

error: failed to get `outbox-pattern-processor` as a dependency of package `anti-fraud-service v0.1.0 (/project/your-project)`

Caused by:

  failed to load source for dependency `your-lib`

Caused by:

  Unable to update https://github.com/your-company/your-lib.git?tag=v1.0.0#49efa247

Caused by:

  failed to fetch into: /home/tiago.motta/.cargo/git/db/your-lib-31d59910066df49a

Caused by:

  revision 49efa2476e2613cf809315b4b0abf16f079b5dcb not found

Caused by:

  failed to authenticate when downloading repository

  * attempted to find username/password via git's `credential.helper` support, but failed

  if the git CLI succeeds then `net.git-fetch-with-cli` may help here

  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:

  failed to acquire username/password from local configuration

The solution is simple. Just edit your global .gitconfig to replace HTTPS URLs with SSH by adding the following lines:

[url "ssh://git@github.com/"]

insteadOf = https://github.com/

What is the best rust lib to post custom metric on datadog?

The best library for recording custom metrics in Datadog using Rust is dogstatsd (https://crates.io/crates/dogstatsd).

The alternative statsd (https://crates.io/crates/statsd) does not allow sending tags. There is even a fork, datadog-statsd (https://crates.io/crates/datadog-statsd), that enables tag sending. However, both define the client without deriving Clone, which prevents using this client as with_state in Axum, resulting in an error similar to this:

the trait bound `...` is not satisfied

the trait `Clone` is not implemented for `...`rustcClick for full compiler diagnostic

method_routing.rs(168, 16): required by a bound in `post`

....rs(6, 1): consider annotating `...` with `#[derive(Clone)]`: `#[derive(Clone)]

`

the trait bound `...` is not satisfied

the trait `Clone` is not implemented for `...`rustcClick for full compiler diagnostic

method_routing.rs(168, 16): required by a bound in `post`

....rs(6, 1): consider annotating `...` with `#[derive(Clone)]`: `#[derive(Clone)]

`

the trait bound `fn(axum::extract::State<...>, Json<...>) -> impl futures::Future<Output = Result<hyper::Response<axum::body::Body>, AppError>> {...::handler}: Handler<_, _>` is not satisfied

the following other types implement trait `Handler<T, S>`:

  `Layered<L, H, T, S>` implements `Handler<T, S>`

  `MethodRouter<S>` implements `Handler<(), S>`rustcClick for full compiler diagnostic

....rs(55, 32): required by a bound introduced by this call

method_routing.rs(166, 16): required by a bound in `post`

the trait bound `fn(axum::extract::State<...>, axum::Json<...>) -> impl futures::Future<Output = Result<hyper::Response<axum::body::Body>, ...>> {...}: Handler<_, _>` is not satisfied

the following other types implement trait `Handler<T, S>`:

  `Layered<L, H, T, S>` implements `Handler<T, S>`

  `MethodRouter<S>` implements `Handler<(), S>`rustcClick for full compiler diagnostic

....rs(55, 32): required by a bound introduced by this call

method_routing.rs(166, 16): required by a bound in `post`

axum::routing::method_routing

pub fn post<H, T, S>(handler: H) -> MethodRouter<S, Infallible>

where

    H: Handler<T, S>,

    T: 'static,

    S: Clone + Send + Sync + 'static,

H = fn handler(State<...>, …) -> …, S = ...

 

Solution to failed to run custom build command for `openssl-sys v0.9.104`

 When upgrading "reqwests" library I got the following error on docker build:

#18 182.8 The following warnings were emitted during compilation:

#18 182.8 

#18 182.8 warning: openssl-sys@0.9.104: Could not find directory of OpenSSL installation, and this `-sys` crate cannot proceed without this knowledge. If OpenSSL is installed and this crate had trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the compilation process. See stderr section below for further information.

#18 182.8 

#18 182.8 error: failed to run custom build command for `openssl-sys v0.9.104`

#18 182.8 

#18 182.8 Caused by:

#18 182.8   process didn't exit successfully: `/usr/app/target/release/build/openssl-sys-ff7852766e78b685/build-script-main` (exit status: 101)

#18 182.8   --- stdout

#18 182.8   cargo:rustc-check-cfg=cfg(osslconf...

 

Could not find the solution after googling, but I tried the obvious solution, install openssl-dev into the docker image:

FROM rust:1.82-alpine AS builder

RUN apk add --no-cache openssl-dev

After this I got the following error:

x86_64-alpine-linux-musl/bin/ld: cannot find -lssl: No such file or directory

x86_64-alpine-linux-musl/bin/ld: cannot find -lcrypto: No such file or directory

And the fix for this was adding the openssl-libs-static:

FROM rust:1.82-alpine AS builder

RUN apk add --no-cache openssl-dev openssl-libs-static

 

Fixed

Solution to cargo-tarpaulin and missing `GLIBC_2.38' not found

Using cargo-tarpaulin 0.31.4 using binstall on Ubuntu 22.04 may result in errors like the following:

cargo-tarpaulin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by cargo-tarpaulin)

cargo-tarpaulin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by cargo-tarpaulin)

I resolved the issue by avoiding binstall. Instead of running: 

I resolved the issue by avoiding binstall. Instead of running

> cargo binstall cargo-tarpaulin

I used the following command:

> cargo insatall cargo-tarpaulin

While this installation method is significantly slower, it successfully resolves the issue.

I suspect similar problems could arise with other Rust libraries when using binstall.

The non-experimentation result anti-pattern

Many of us have gone through the scenario of putting new software functionality into production and seeing tremendous improvement in business metrics. These results are often celebrated and attributed to this new achievement and this is used in presentations and corporate bonuses definitions.

But can we attribute causal relation between the new functionality and the new business metrics?

Before answering this question, however difficult it may be to abandon the emotive side of the functionality we have created, let us try to imagine some hypothesis that might have caused this improvement other than our change:

• An advertising campaign
• An unexpected viral
• The functionality created by another squad
• A concurrent product crashes
• It is a normal seasonal movement

These are just a few assumptions that could cause improvement in metrics. It is possible to mitigate each of them through some data analysis. But can you anticipate all other possible causal assumptions to be able to rule them out? Difficultly.

Since you can not assign causality between the two events, the most you can say is that there is a correlation between them. And yet it may be a spurious correlation. Some examples of this kind of correlations can be seen on this site here. It speaks, for example, about the strong correlation between the number of Nicolas Cage films per year and the number of drownings in the United States per year.

So the answer to the initial question is no! It is not correct to attribute the improvement of the business metric just because of its new functionality. If you want to check whether a new feature causes a change in some metric, an AB experiment is required.

In an AB experiment we have a variant (or alternative) called control (usually A) and a variant containing the modification to be validated (B). A random sample of users will receive the version of their product with variant A, and another random sample of users will see variant B. Everything in the two variants must be the same, except the modification made in variant B. With this you can control the environment and all those possible causes we reported above and more the others hypothesis we could not predict before.

At the end of the experiment we ate going to be able to attribute the causality of the new functionality to the incremental metric because it was the only thing different in the whole environment. Taking into account of course all statistical variance due to the use of a sample, which can lead us to possible false positives in a minimal percentage of cases.

AB experiments are the most accepted technique currently for you to determine the causality of a change in your product. They are not a new thing and are widely used as a part of the scientific method.

However there is currently a large discussion in the statistical area regarding causal inferences, which would be models for inferring cause from one event to another without necessarily an experiment controlling all variables. This discussion became even stronger after the publication of The Book of Why.

However, if you do not master the techniques of causal inference, it is best not to disclose cause and effect without being sure. I know it's very hard for us to leave our emotions aside for having participated in the development of that piece of software. But it's important to stay cool. And of course, always do AB experiments before putting something into production.

This post is part of a series about Experimentation Anti-Patterns, a talk that I presented recently.