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

Fix publish to allow for dev-dependencies to have circular references #9579

Closed
Omega359 opened this issue Mar 12, 2024 · 3 comments
Closed
Labels
enhancement New feature or request

Comments

@Omega359
Copy link
Contributor

Omega359 commented Mar 12, 2024

Is your feature request related to a problem or challenge?

Currently we cannot have any dev-dependencies in the Cargo.toml files that would cause circular references because cargo publish in all it's wisdom doesn't exclude dev-dependencies when publishing to crates.io. This causes issues with tests where we either have to move the test to some 'common' location when the test wants to use a dependency that we otherwise do not want in the crate (for example, a dependency on datafusion-functions in the physical-expr crate), remove the test or somehow rewrite the test to not require the dependency. This is pretty limiting and really shouldn't be an issue.

I propose that the cargo publish commands that are used are tested with the --no-dev-deps flag from the hacks crate. If successful we could then once again allow the circular dev-dependencies which would ease testing.

Note that this change would not allow for dev-dependencies in rust docs -- it would likely work locally but I believe would likely still fail when published.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

@alamb
Copy link
Contributor

alamb commented Mar 13, 2024

cc @andygrove

I am not 100% convinced that having the circular back references as dev-dependencies is a good idea (as it complicates / slows down cargo test -b <crate>

If we need to depend on more crates, pulling the tests into datafusion_core is probably the better approach

@andygrove
Copy link
Member

Sorry, but I'm not a fan of this approach. I think it is good to avoid circular dependencies of any kind. We should use rustdoc only to document the contents of a crate and not need to reference "parent" crates.

I think that the real issue here is that we don't have a good way yet to have end-to-end user documentation that includes Rust fragments that are tested for correctness. I would prefer that we find a solution to that problem.

@Omega359
Copy link
Contributor Author

Closing as won't do.

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

No branches or pull requests

3 participants