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

cargo publish behaves differently than cargo test in workspace with prepared data #3644

Open
mhatzl opened this issue Dec 17, 2024 · 6 comments
Labels

Comments

@mhatzl
Copy link

mhatzl commented Dec 17, 2024

Bug Description

I have a workspace setup, where I ran cargo sqlx prepare --workspace.
The workspace repository is public at https://github.com/mhatzl/mantra
You can see that there is a .sqlx folder at workspace root, and also a mantra.db SQLite database file used to prepare the queries for offline use.

The SQLX_OFFLINE env is set to true to force SQLX to also use the prepared data for local development.

I am able to build and test the whole workspace by running cargo test.
Therefore, all SQL queries inside the mantra crate, located at /mantra in the workspace, should be correct.

However, running cargo publish --package mantra at workspace root fails, because SQLX cannot find the ".sqlx" folder.

Running cargo publish --package mantra --no-verify works, but then installing mantra using cargo install mantra fails.

I have tried to prepare and publish mantra from the subfolder, but the behavior remained the same.

No idea what I am missing, because cargo test works, but cargo publish fails to build.

Minimal Reproduction

A bit tough to reproduce without publishing some crate using cargo publish.

Info

  • SQLx version: 0.7.4
  • SQLx features enabled: "sqlite", "json", "runtime-tokio", "time"
  • Database server and version: SQLite
  • Operating system: Windows 10
  • rustc --version: 1.82.0
@mhatzl mhatzl added the bug label Dec 17, 2024
@mhatzl
Copy link
Author

mhatzl commented Dec 17, 2024

Tried it with SQLx version 0.8.2, but it has the same behavior :/

@mhatzl
Copy link
Author

mhatzl commented Dec 19, 2024

Setting SQLX_OFFLINE_DIR to the absolute path for the .sqlx folder in the workspace solved the compiler error for cargo publish, but cargo install of the published binary fails with:

set DATABASE_URLto use query macros online, or runcargo sqlx prepare to update the query cache

It seems it is not saving the offline data somehow.

I have successfully published this crate with older rustc versions, so I am not sure what broke.

@mhatzl
Copy link
Author

mhatzl commented Dec 19, 2024

Setting SQLX_OFFLINE = true before running cargo install leads to:

SQLX_OFFLINE=true but there is no cached data for this query, run cargo sqlx prepare to update the query cache or unset SQLX_OFFLINE

@abonander
Copy link
Collaborator

Publishing mantra only includes the contents of the mantra/ folder. It doesn't include the whole workspace.

https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields

@mhatzl
Copy link
Author

mhatzl commented Dec 20, 2024

ah thank you. didn‘t know about this.

about finding the workspace root:
I was able to resolve this in another crate of mine using the cargo „locate-project“ command with the —workspace argument.
https://github.com/mhatzl/embedded-runner/blob/621fde6f2ae5e958b3b16c8926e29cf48396cb70/src/path.rs#L17

You are using this command already, but without the workspace argument.
Might help to correctly locate the .sqlx folder.

@mhatzl
Copy link
Author

mhatzl commented Dec 22, 2024

I tried to set the following include paths in mantra/Cargo.toml:

include = ["../.sqlx", "src/", "examples/usage", "examples/mantra.toml", "examples/usage.rs", "migrations/"]

cargo publish --package mantra runs successfully if I set SQLX_OFFLINE_DIR to the absolute path.
However, cargo install mantra still fails, because the ../.sqlx folder seems to not be copied even though I explicitly set it in the include setting.

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

No branches or pull requests

2 participants