Rust setup and install section of readme files

[sanders41]

In the setup section of the readme files for Rust it has people install the dependencies like:

cargo add csv
cargo add dotenvy
cargo add sqlx
cargo add postgres
cargo add rand
cargo add serde --features derive
cargo add tokio --features full

This isn't wrong, but since we already have all the dependencies in the Cargo.toml files it also isn't needed. So as a general question, should we remove this from the readme's and discuss how to add dependencies as a broader topic in the book instead?

[prrao87]

This is something I haven't found a good answer to in my reading: how do newcomers to Rust know how to update a new Cargo.toml file with the right/latest versions of the crate? Is there a good way to do this other than using cargo add?

My problem initially was that for crates like serde and tokio, it's also not obvious how to access the derive traits until you specify the right features flag.

For example, how is one supposed to know the .toml syntax for specific features as shown below without using cargo add?

serde = { version = "1.0.193", features = ["derive"] }
sqlx = { version = "0.7.3", features = ["runtime-tokio", "postgres"] }
tokio = { version = "1.35.1", features = ["full"] }

In Python, we construct the requirements.txt file by hand, but it's at least a simple text file and that's how we can get away with just calling pip install -r requirements.txt. In Rust, it's hard to explain how the Cargo.toml magically constructs itself, which is why I wanted to included this in the docs as well. Or am I missing something basic and there's an easier way? 😅

[prrao87]

Another related question I had when making the repo was: is it common practice to commit the Cargo.lock to GitHub? If I understand correctly, if using poetry in Python, you just commit pyproject.toml and not the lock file - is that the best practice in Rust repos too?

[prrao87]

I suppose what I'm asking is, should Cargo.lock be added to the .gitignore 😅

[sanders41]

Yeah, this point is why I don't think there is a clear right answer. When I first looked at the readme I thought I was missing something because it said to add the packages and they were already there. But you are right that someone who hasn't worked with rust before wouldn't know that or know how the packages got there.

[prrao87]

Yeah, I've seen YouTube videos where people manually type in the version numbers of a crate into the toml file, which drives me crazy. That's why I tried to see this through the lens of someone who wants to learn how the file got constructed in the first place, so I suppose that could be worded better in the README

[sanders41]

When I started with Rust there wasn't a cargo add so you had to do it manually, it's a more recent addition...that was badly needed 😀

If someone was to run the add commands it won't cause any problems so it won't hurt to leave them in.

[prrao87]

@sanders41 On this topic, I was thinking about how to add documentation for the Python venv setup. I know you're a poetry fan and use it in all your projects, but poetry never really resonated with me because I find its dependency resolver really slow and it just feels "heavy" compared to pip. I'd love to keep this repo simple and just use pip to install Python packages throughout. I'm also thinking a bit ahead where I may want to install ML libraries and such, and pip is always something that's supported and in the docs of every well-known Python library.

This would require that users install self-contained virtual environments in each piece's subdirectory, so it would require updates to the docs in a way that I normally do in my repos:

Setup

Install the dependencies in a virtual environment via requirements.txt.

# First time setup
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt

# For subsequent runs, simply activate the environment
source venv/bin/activate

Does this make sense?

[sanders41]

Yes, in this situation I would not use Poetry. The idea here is for Python developers to learn Rust. With that in mind everyone will have pip, but not everyone will have Poetry, pipenv, or whatever other tool we could choose so that would just add unnecessary complication.

[prrao87]

Yup, and also the philosophy here in general is to use what the larger community uses, and pip and cargo are those tools. pytest makes sense over the inbuilt unittest module (ugh) for the same reason.