WIP: injecting builder implementation from CargoBuild #68
Conversation
AnderEnder
commented
Jan 6, 2019
AnderEnder
commented
- inject CargoBuild builder into CommandCargoExt
- implement CommandCargoBuildExt to finish the builder
AnderEnder
force-pushed
the
cargo-build-trait
branch
from
4d909f8 to
9d9edf6
Compare
AnderEnder
force-pushed
the
cargo-build-trait
branch
from
9d9edf6 to
eab1076
Compare
There was a problem hiding this comment.
Some concerns I have with going this direction
- See my other comment about going 1.0
- I feel weird putting a factory on one type (
Command) for other types (CommandorPathBuf) - Previously, I've taken the stance of simple, quick and dirty use cases are built in and advanced use cases are when someone should go to escargot. This blurs that line. For heavy testing, someone probably needs to be caching the binary which this doesn't support but this does support all of the other "heavy lifting" API features.
Maybe it could help if you clarified what is your motivation for building all of this in rather than reaching to escargot for these cases?
| @@ -18,7 +18,7 @@ name = "bin_fixture" | |||
| predicates = { version = "1.0", default-features = false, features = ["difference"] } | |||
| predicates-core = "1.0" | |||
| predicates-tree = "1.0" | |||
| escargot = "0.3" | |||
| escargot = "0.4" | |||
There was a problem hiding this comment.
I've been working towards assert_cmd being 1.0. The current quiet period is me awaiting feedback. Escargot is further from 1.0. It is a lot closer now after my recent PRs but I still want to get some more practical usage out of it first (like with stager / cargo-tarball).
Even once escargot goes 1.0, I expected to not have much resistance to creating a 2.0, etc because I was not expecting it to be in APIs of other crates. Putting it in another crate's API makes me want to make sure the API is even more solid and could delay 1.0.
|
Closing in favor of #69 |
