Cant declare inline tests with dependencies #202
Comments
|
Currently you can only omit sources when deps is exactly 1 crate, otherwise
we can't figure out which depending to build tests for.
…On Thu, Mar 7, 2019, 18:36 Greg Bowyer ***@***.***> wrote:
Sorry if this is already raised
Consider a file like so
fn some_fn() -> u32 {
2
}
#[cfg(test)]mod tests {
use super::some_fn();
// This following line is not going to work
use pretty_assertions::assert_eq;
#[test]
fn test_is_2() {
assert_eq!(1, some_fn());
}
}
With a build function like so
rust_library(
name = "example",
srcs = ["lib.rs"]
)
rust_test(
name = "example_test",
deps = [
":example",
"//third_party/rust:pretty_assertion",
],
)
You will get an error along the lines of
attribute srcs: No lib.rs or example_test.rs source file found.
Is there something I am missing?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#202>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACLjeF8YNpC7geNPtoaD7BhntjAcat6uks5vUaJ7gaJpZM4bkVpP>
.
|
GregBowyer
added a commit
to GregBowyer/rules_rust
that referenced
this issue
Mar 8, 2019
Due to the way unit tests are handled with the rules, it is tricky for a
unit test to have additional deps.
Consider some source code like such
```rust
fn some_fn() -> u32 {
2
}
mod tests {
use super::some_fn();
// This following line is not going to work
use pretty_assertions::assert_eq;
#[test]
fn test_is_2() {
assert_eq!(1, some_fn());
}
}
```
With a build function like so
```python
rust_library(
name = "example",
srcs = ["lib.rs"]
)
rust_test(
name = "example_test",
deps = [
":example",
"//third_party/rust:pretty_assertion",
],
)
```
Presently, due to the handling of ‟unit tests” the extra deps will
conflict with rust_rules ideas about how to identify the test, and give
an error along the lines of
```
attribute srcs: No lib.rs or example_test.rs source file found.
```
With this change we make it possible for tests to express ‟dev
dependencies”. This lets us avoid adding deps that are strictly for
testing.
This is somewhat distinct from `testonly` attributes as it does not
always hold that a dependency is always and only ever `testonly` in all
library circumstances, consider for example the usage of
https://github.com/pingcap/fail-rs. There are instances where this needs
to be used both in source code *and* test code, and is not easily
seperated from a cargo-raze perspective.
Closes bazelbuild#202
|
@mfarrugi I think there are two possible solutions. One is to allow tests to maybe have a I think the first is a little more idiomatic to how Rust / Cargo works and is possibly easier for those coming from Cargo to understand, albeit at the cost of being a little none-typical for looking like idiomatic Bazel. With that said language rules can naturally have extensions that are specialised (for instance Thoughts ? ideas? |
|
dev_deps looks fine, though I think it might be better to demagic deps with
1 crate (eg. Changing the parameters to (srcs or test_crate) and deps) or
move the dev_deps attribute to the library/binary rules.
I don't see anything about test_only in cc_library, but this seems
reasonable too. I guess the extreme version of this would be a
`cargoish_project` macro that creates a library, binary, test, docs, and
doctest target.
…On Thu, Mar 7, 2019, 19:15 Greg Bowyer ***@***.***> wrote:
@mfarrugi <https://github.com/mfarrugi> I think there are two possible
solutions.
One is to allow tests to maybe have a dev_deps attribute (see #203
<#203>).
The other one might be to fiddle about with the notion of test_only deps
(similar to the cc_library rule does).
I think the first is a little more idiomatic to how Rust / Cargo works and
is possibly easier for those coming from Cargo to understand, albeit at the
cost of being a little none-typical for looking like idiomatic Bazel. With
that said language rules can naturally have extensions that are specialised
(for instance crate_type) so its not impossible to take such an approach.
Thoughts ? ideas?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#202 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACLjeLMaQH0ikGhHWXICjyZubemna4Skks5vUauIgaJpZM4bkVpP>
.
|
|
Just got bit by this - for what it's worth, I'd vote having a |
GregBowyer
added a commit
to GregBowyer/rules_rust
that referenced
this issue
Apr 4, 2019
Due to the way unit tests are handled with the rules, it is tricky for
a crate containing internal test configuration to have additional (test
only) deps.
Consider some source code like such
```rust
fn some_fn() -> u32 {
2
}
mod tests {
use super::some_fn();
// This following line is not going to work
use pretty_assertions::assert_eq;
#[test]
fn test_is_2() {
assert_eq!(1, some_fn());
}
}
```
With a build function like so
```python
rust_library(
name = "example",
srcs = ["lib.rs"]
)
rust_test(
name = "example_test",
deps = [
":example",
"//third_party/rust:pretty_assertion",
],
)
```
Presently, due to the handling of ‟unit tests” the extra deps will
conflict with rust_rules ideas about how to identify the test, and give
an error along the lines of
```
attribute srcs: No lib.rs or example_test.rs source file found.
```
With this change we make it possible for tests to express ‟dev
dependencies”. This lets us avoid adding deps that are strictly for
testing.
This is somewhat distinct from `testonly` attributes as it does not
always hold that a dependency is always and only ever `testonly` in all
library circumstances, consider for example the usage of
https://github.com/pingcap/fail-rs. There are instances where this needs
to be used both in source code *and* test code, and is not easily
seperated from a cargo-raze perspective.
Closes bazelbuild#202
WIP
GregBowyer
added a commit
to GregBowyer/rules_rust
that referenced
this issue
Apr 4, 2019
Due to the way unit tests are handled with the rules, it is tricky for
a crate containing internal test configuration to have additional (test
only) deps.
Consider some source code like such
```rust
fn some_fn() -> u32 {
2
}
mod tests {
use super::some_fn();
// This following line is not going to work
use pretty_assertions::assert_eq;
#[test]
fn test_is_2() {
assert_eq!(1, some_fn());
}
}
```
With a build function like so
```python
rust_library(
name = "example",
srcs = ["lib.rs"]
)
rust_test(
name = "example_test",
deps = [
":example",
"//third_party/rust:pretty_assertion",
],
)
```
Presently, due to the handling of ‟unit tests” the extra deps will
conflict with rust_rules ideas about how to identify the test, and give
an error along the lines of
```
attribute srcs: No lib.rs or example_test.rs source file found.
```
With this change we make it possible for tests to express ‟dev
dependencies”. This lets us avoid adding deps that are strictly for
testing.
This is somewhat distinct from `testonly` attributes as it does not
always hold that a dependency is always and only ever `testonly` in all
library circumstances, consider for example the usage of
https://github.com/pingcap/fail-rs. There are instances where this needs
to be used both in source code *and* test code, and is not easily
seperated from a cargo-raze perspective.
Closes bazelbuild#202
WIP
GregBowyer
added a commit
to GregBowyer/rules_rust
that referenced
this issue
Apr 4, 2019
Due to the way unit tests are handled with the rules, it is tricky for
a crate containing internal test configuration to have additional (test
only) deps.
Consider some source code like such
```rust
fn some_fn() -> u32 {
2
}
mod tests {
use super::some_fn();
// This following line is not going to work
use pretty_assertions::assert_eq;
#[test]
fn test_is_2() {
assert_eq!(1, some_fn());
}
}
```
With a build function like so
```python
rust_library(
name = "example",
srcs = ["lib.rs"]
)
rust_test(
name = "example_test",
deps = [
":example",
"//third_party/rust:pretty_assertion",
],
)
```
Presently, due to the handling of ‟unit tests” the extra deps will
conflict with rust_rules ideas about how to identify the test, and give
an error along the lines of
```
attribute srcs: No lib.rs or example_test.rs source file found.
```
With this change we make it possible for tests to express ‟dev
dependencies”. This lets us avoid adding deps that are strictly for
testing.
This is somewhat distinct from `testonly` attributes as it does not
always hold that a dependency is always and only ever `testonly` in all
library circumstances, consider for example the usage of
https://github.com/pingcap/fail-rs. There are instances where this needs
to be used both in source code *and* test code, and is not easily
seperated from a cargo-raze perspective.
Closes bazelbuild#202
WIP
GregBowyer
added a commit
to GregBowyer/rules_rust
that referenced
this issue
Apr 5, 2019
Due to the way unit tests are handled with the rules, it is tricky for
a crate containing internal test configuration to have additional (test
only) deps.
Consider some source code like such
```rust
fn some_fn() -> u32 {
2
}
mod tests {
use super::some_fn();
// This following line is not going to work
use pretty_assertions::assert_eq;
#[test]
fn test_is_2() {
assert_eq!(1, some_fn());
}
}
```
With a build function like so
```python
rust_library(
name = "example",
srcs = ["lib.rs"]
)
rust_test(
name = "example_test",
deps = [
":example",
"//third_party/rust:pretty_assertion",
],
)
```
Presently, due to the handling of ‟unit tests” the extra deps will
conflict with rust_rules ideas about how to identify the test, and give
an error along the lines of
```
attribute srcs: No lib.rs or example_test.rs source file found.
```
With this change we make it possible for tests to express ‟dev
dependencies”. This lets us avoid adding deps that are strictly for
testing.
This is somewhat distinct from `testonly` attributes as it does not
always hold that a dependency is always and only ever `testonly` in all
library circumstances, consider for example the usage of
https://github.com/pingcap/fail-rs. There are instances where this needs
to be used both in source code *and* test code, and is not easily
seperated from a cargo-raze perspective.
Closes bazelbuild#202
WIP
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sorry if this is already raised
Consider a file like so
With a build function like so
You will get an error along the lines of
Is there something I am missing?
The text was updated successfully, but these errors were encountered: