Closed gregschmit closed 1 year ago
Hey, I was actually wondering about that as I went through the code. Bellow are my thoughts on it.
I don't see much use for a library tbh, it adds a fair bit of maintenance overhead for little benefit as I see it, so unless you have a specific use-case in mind I'm for dropping the lib aspect in favor of better and more maintainable code in the bin crate.
Also another benfit of a pure bin, i you don't have API concerns, as long as we are stable with the CLI everything else is implementation details that we are at will to alter. I also tend to go for a very sctrict and stable API even for libs, see daemonize-me for an example of what I mean, everything not in the main struct and accessors is implementation detail and subject to change.
Yeah I agree with everything you said.
Want any help with this one?
I can handle this one.
Ok, I will wait for you to finish this before picking up another issue, because this one is very much the definition of there would be conflicts.
Fixed in c7e86c126a14ff6828636af23bef1fac3ce2f4fd
In my excitement of learning common patterns in Rust, I might have over-engineered this project. Currently it is separated into a
lib
crate and abin
crate, the idea being to separate concerns of core logic and frontend, and also so certain logic could be reused if another project wanted to, for example, make a different frontend toomake
.The problem I'm seeing is that I had to separate
Args
andOpts
struct so thelib
would not depend onclap
, and this requires manual duplication of a handful of struct fields that must be kept in sync. Furthermore, sub-MAKE (related to #8) would need to know the command line options to execute and would need to know how the parent process was invoked, so it seems like a lot of the backend logic is tightly coupled to the binary aspect of this project.I'm considering removing the
lib
crate and just making this project a singlebin
crate.Thoughts?
@neonimp