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

Testing whole workspace with features enabled in some crate(s) #6195

Open
djc opened this issue Oct 20, 2018 · 4 comments
Open

Testing whole workspace with features enabled in some crate(s) #6195

djc opened this issue Oct 20, 2018 · 4 comments

Comments

@djc
Copy link
Contributor

@djc djc commented Oct 20, 2018

Problem
I have a workspace with a testing crate and some unit tests in other crates. Some tests need big dependencies, so I'd like to disable these by default and enable them only in CI. In CI, I then want to run all the tests, enabling the features for these tests. Here are some things I've tried:

cargo test --all --features dependency-test
cargo test --all --features testing/dependency-test (testing is the directory the testing crate lives in relative to the workspace root)
cargo test --all --features project_testing/dependency-test (project_testing is the package.name for the testing crate)

However, none of these seem to actually run the tests in question, whereas I'd expect at least one of them would (most likely the latter one?).

Actual use case is https://github.com/djc/askama, the actix feature in the testing crate. (Prototype change is here: https://github.com/djc/askama/compare/actix-off?expand=1).

Testing with stable Rust/Cargo on either macOS or (Linux) Travis.

@ehuss

This comment has been minimized.

Copy link
Contributor

@ehuss ehuss commented Oct 20, 2018

Some workarounds:
cargo test -p askama_testing --features "actix" -Z package-features
or cd into each directory and run cargo test within it. AFAIK you can't do all packages at once. Currently in a workspace the features selected depends on which directory you are in (-Z package-features changes this behavior).

@djc

This comment has been minimized.

Copy link
Contributor Author

@djc djc commented Oct 20, 2018

I understand about the workaround of cding into a particular directory, but that means either making the Travis config more complex by specifying all contained crates separately, or making the test suite slower to run because some tests are run twice.

Since I'm running this at the top of the workspace, I think there are two reasonable conceptual models that could work: either I'm one level "above" the crates, and I should be able to use a crate/feature value to select a feature in the crates, or my command is more or less "copied" into each crate, in which case I should be able to use the bare feature.

If neither of these work, it seems like there is a conceptual hole in the workspace implementation (or how the test command interacts with it).

@ehuss

This comment has been minimized.

Copy link
Contributor

@ehuss ehuss commented Oct 20, 2018

Yea, I agree there should be some way to do it. Typically the form foo/bar for features means the bar feature of the foo dependency, but in a virtual workspace there is no foo dependency (there is a foo member). So it may be confusing what that actually means. It may also be confusing on how to select features when building multiple packages (which is why I believe -Z package-features prevents you from trying).

This has been reported several times (#4753, #4106, #4463, #5364, etc.), so you're not alone. I'm trying to collect all the issues with features to see if there is a cohesive way to deal with them all.

@ehuss ehuss added the A-features label Nov 18, 2018
bors added a commit that referenced this issue Oct 15, 2019
Reject feature flags in a virtual workspace.

This generates an error if feature flags are used in the root of a virtual workspace. Previously these flags were completely ignored.  In the interest of avoiding confusion, I think it would be good to be explicit that these don't currently work.  This could alternatively be a warning, but I think it is better to reject it outright.

cc #4753, #3620, #5015, #6195, etc.
bors added a commit that referenced this issue Oct 15, 2019
Reject feature flags in a virtual workspace.

This generates an error if feature flags are used in the root of a virtual workspace. Previously these flags were completely ignored.  In the interest of avoiding confusion, I think it would be good to be explicit that these don't currently work.  This could alternatively be a warning, but I think it is better to reject it outright.

cc #4753, #3620, #5015, #6195, etc.
@djc

This comment has been minimized.

Copy link
Contributor Author

@djc djc commented Jan 27, 2020

@ehuss -- more than a year later -- do you have any ideas on how we could move this forward?

It still seems to me that the dependency vs member difference is small enough that we can paper over it in this case; conceptually, a workspace already in some ways acts like a meta-crate that depends on all (or some, with default-members) of its members.

@ehuss ehuss added the A-workspaces label Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.