Make rusqlite optional

[hugocaillard]

This PR is part of an initiative to reduce the size and the impact of #4756.

Description

Isolate the rusqlite dependency in stacks-common and clarity behind a cargo feature.
This allows to use the clarity-vm without the rusqlite dependency, as it's done in Clarinet.

This PR adds a canonical cargo feature to stacks-common and clarity.
Ultimately, the cargo features of these 2 Cargo.toml will get more complex, as they are in #4756 (see here and there). But compared to the other PR, I didn't add a extra sqlite feature which appears to be useless.

Question:

• does the cargo feature management seem ok? (knowing that it will get more complex)

To make sure that the PR works as expected, you can run

> cargo check -p clarity
> cargo check -p clarity  --no-default-features --features=developer-mode
# I may want to add that to the CI

And make sure that rusqlite isn't pulled in clarity

> cargo tree -i rusqlite -p clarity  --no-default-features --features=developer-mode

(should output error: package ID specification rusqlite did not match any packages)

Applicable issues

• Related to Merge feat/clarity-wasm-next #4509

Additional info (benefits, drawbacks, caveats)

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[obycode]

LGTM!

[jcnelson]

LGTM; just a couple nits to address before approving

[jcnelson]

Also, I think you should update CI with these cargo check statements so we can be certain that Clarity remains isolated from rusqlite.

[kantai]

LGTM, just address Jude's comments

[hugocaillard]

@wileyj I'd like to add cargo check -p clarity --no-default-features --features=developer-mode somewhere in the CI, what would be the best place to do so?

Note: in the feature we'll also add checks to make sure that clarity compile to --target wasm32-unknown-unknown, it'll require some more work to get there

[wileyj]

@wileyj I'd like to add cargo check -p clarity --no-default-features --features=developer-mode somewhere in the CI, what would be the best place to do so?

Note: in the feature we'll also add checks to make sure that clarity compile to --target wasm32-unknown-unknown, it'll require some more work to get there

can you walk me through what you want to do here? is the idea to adjust a current workflow, or are we adding a new one?
more than likely, this would need to happen in the https://github.com/stacks-network/actions repo vs the stacks-core repo

[hugocaillard]

@wileyj Add a new one. We want to make sure that the clarity package passes the check with no default feature and the developer-mode feature https://github.com/stacks-network/stacks-core/blob/feat/sqlite-feature-flag/clarity/Cargo.toml#L58

We can probably do that outside of this PR i guess

[wileyj]

@wileyj Add a new one. We want to make sure that the clarity package passes the check with no default feature and the developer-mode feature https://github.com/stacks-network/stacks-core/blob/feat/sqlite-feature-flag/clarity/Cargo.toml#L58

We can probably do that outside of this PR i guess

got it - yes, this can be addressed in that actions repo so not a blocker on this PR. i'll ping you outside of this PR

[hugocaillard]

@jcnelson

I think it's better to do the CI work in an other PR. Maybe even after we can compile clarity to wasm

[obycode]

👍

[blockstack-devops]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.