A number of you here on the Rust help forum have been teaching/helping me with both working through the Rust learning curve and dealing with issues I've come up against as my main project -- [Question Bank Creator](GitHub - jtreagan/Question-Bank-Creator -- QBC) -- has been progressing. A week or two ago it finally reached the point that it needed to be uploaded to Github and I've been slowly learning how the Github venue works. However, I am still mostly mystified when it comes to using it properly. I have a pile of questions that I want to ask here and I'm hoping it's okay to air them here. (If there is a more appropriate place to ask these questions, please point me in the right direction. :>) Here is Question #1:
I have several personally-written libraries on which QBC is dependent. If someone wants to compile it, he/she will need to have those files available. How do I deal with that? It was suggested to me that I upload each of these libraries as a separate repository. Is that the best route to take, or is there a better way to make them available? Keep in mind that even as my code for QBC is rough, the code in these crates I'm talking about is also rough.
I would recommend uploading them to Github as well. While you could theoretically vendor them in your project (copy the dependencies into the project and update before each git push), there's no need. Publishing to Github is free and easy, so why not?
Do you foresee distributing those libraries to people who are not planning on using QBC, or are these, at least for the foreseeable future, mainly intended to support QBC?
If they're for QBC, then it's pretty likely that the most practical way to distribute them as source code is alongside QBC, in a multi-crate workspace contained entirely in the QBC repository. Anyone cloning the repository would obtain the source code for QBC as well as the source code for the libraries you've written, and Cargo can build them together or separately as needed.
If they're of more general interest, then it might be prudent to split them out to separate repositories, so that people who want the code for your libraries don't have to contend with the code for QBC as well. You'd stitch them into QBC at build time using Cargo's [dependencies] table, like you would any third-party library. This also means publishing those libraries to crates.io, or using Git dependencies[1] to tell Cargo where to get them when building QBC.
Note that anything published to crates.io cannot have Git dependencies. ↩︎
They really do stand independent of QBC and that is why I put them in separate libraries. They are mostly utilitarian in nature and I have used them as dependencies in other projects.
I've thought about doing that, if just to get the experience, but their quality is far below anything worthy of publishing on crates.io.
There's not much "cost" to publishing on crates.io: the only downside is that there's now one less name available, and now you have to remember to cargo publish (and update your version number).
Ok, now that I have a couple of my utility libraries uploaded to Github repositories, I can see why you're suggesting that I publish these crates on crates.io. I just went through the respective Cargo.toml files for those two crates and deleted unnecessary dependencies. However, it will still be clumsy for anyone wanting to either compile QBC or use those crates independently because up until now I have referenced them via a directory path to where I have them stored locally. For instance, the dependency paths in QBC's Cargo.toml that reference those crates, needs to be different in the Cargo.toml listed in QBC's Github repository. Again, I'm somewhat mystified as to how to accomplish that.
Not really - not if you list them as regular dependencies. Given your questions so far, you might want to skim through the Cargo Guide in full (it's quite short), before trying to accomplish anything specific.
Code wise, in general, referencing your own (local machine's) files as in:
let filename = "/home/jtreagan/programming/rust/mine/tr_rbld1/David_config.yaml";
is not, as far as know, an exemplary practice. Similarly, including your own credits/copyrights as const AUTHOR: &str might not fair any better than wrapping them in a comment. On GitHub, in particular, it's common to provide your own LICENSE.txt file in the root directory, to begin with.
(GitHub conventions are way out of the scope of this forum, though).
Furthermore, seeing how many times you've declared fn's with &String arguments, only to convert them back into &str via .as_str() immediately in the body of the function itself, you might want to read a little bit more about owned vs borrowed types (and String vs &strspecifically, in your case).
Short version: prefer passing in borrowed data (&str/&[u8]) over owning types (String/Vec<u8>).
Other than that - looks like a neat little thing. Good job, and good luck bringing it to fruition.
It seems to me that I already explored using &str rather than String and there was some reason why I decided to go with passing String. Still, I think I'll revisit the topic. I've learned a lot about coding in Rust since I first wrote those functions. Maybe some changes are in order. Thanks for checking out my code! :>)
Well, this is where it may not be the best thing to take your AI too seriously. The AI that goes with my IDE offered that format one day and I went with it. In my QBC project I use some of those constants to create a label for the main window, but the rest of them are just filler.
Actually, I'm posting here because I really had no idea where else to post questions about Github conventions. Could you suggest a better place? Besides, your answer is well thought out and helpful. That helps inexperienced guys like me.
