To Make or Not to Make – Using cargo make for Rookeries v0.12.0

I was pleasantly surprised when my last blog post about migrating to Rust’s integration tests really took off on Twitter. I did not quite expect that much interest. 🙂

Using cargo-make

I recently continued with my exploration of Rust through Rookeries (my attempt at a static site generator/backing API server). This time I worked on switching over from using invoke and GNU make to using a nice build system called cargo-make. Overall I am quite happy with the result. To give you a taste of how cargo-make describes build tasks and environment variables, I included a short snippet from the Rookeries Makefile.toml below:

<br />
[env]
SERVER_PORT = "5000"

[tasks.build-js]
description = "Build JS frontend."
command = "npm"
args = ["run", "build"]

[tasks.run-dev-server]
description = "Run a Rookeries dev server."
command = "cargo"
args = ["run", "--", "run", "${SERVER_PORT}"]
dependencies = ["build-js"]

Much like invoke and Make, you can specify dependencies. Unlike Make, there is no weird tab-based syntax, or implicit behaviour that requires a look up in the GNU Make manual. Just a simple TOML file. Environment variables can be specified in standalone .env files, passed in or specified in the Makefile.toml itself, and allow for variables specified during a run to override defaults, etc. cargo-make also lets you use conditional logic but I did not need to use that for my purposes.

For Rookeries, I ended up creating locally running tasks, and versions for the Dockerized build setup that I have in CircleCI. Also I ended up using the scripting support that cargo-make provides for preparing the database for, and running the integration tests.

My Thoughts on CouchDB for Rookeries and Rust

I feel I cheated a bit towards the end especially by using a few curl commands to instantiate the CouchDB database, and with running the API integration tests. Maybe I should of wrote a proper CouchDB library and utility. However I decided against it, simply because I want move away from CouchDB for Rookeries. So I may not want to invest that much time in maintaining a proper database client if I’ll end up switching over to using Postgresql via diesel.rs Originally, I started using CouchDB because I use it heavily at my work at Points. As time goes on, I find myself more and more reluctant with using CouchDB, just because of all the issues I’ve experienced at work. That said, if someone wants me to maintain a CouchDB Rust library/CLI based on the code I have for Rookeries, then please reach out to me. The CouchDB crates I saw in crates.io did not inspire me, so I wrote my own CouchDB module in Rust. But I don’t want to maintain that code just for myself, so if anyone actually needs a proper CouchDB crate and wants me to maintain it, please reach out to me.

Update – Sofa Library

After I wrote this blog post originally, I did not know about this nice CouchDB crate called sofa. If I had know about it, I would of not bothered with my own implementation.

New Release of Rookeries – Now 100% Rust

Finally since this migration was a bit of work, so I decided to release a new version of Rookeries. Since the invoke setup was the last Python code, Rookeries is now 100% completely written in Rust. (And the JS frontend naturally.) The Rookeries Docker image is available on Docker Hub. The project is still quite in flux, and what I will work on next depends on what I need to do to hook up Rookeries to one of my Gatsby powered sites.

Automagic Code Generation…?

Another morning. A bit wet but perfect for mlaren racing as the soil gets nicely packed and allows for better traction. Now if only I had the time to start upon that project…

As my systems programming and data structures exams loom ever closer, I continue in my quest of understanding the material better by hacking a few applications. I finally found one idea to test my knowledge of thread programming using the POSIX compliant thread libraries. It will be a simulation of a small development team using an revision control server. One of the servers will be use a locked commit (e.g. Visual SafeSource), and the other will use the better method (e.g. CVS, Subversion). Should be interesting…

For my other system programming, I plan on making a useful pipe, and redirect program. PNP (PNP is Not a Pipe) will let you to execute a command, and pipe or redirect the output to another program or file, while enabling you to see all the output being displayed to the screen.

As for my data structure work… I will get on it as soon as I can.

Talked to Kat yesterday shortly, but that definitely made my day. I promptly ruined my day by being lazy, which made my folks irk. Today, I plan to balance work and study a bit better, and not be such a lazy bum. One good thing was that I started on a Herculean task of figuring the GNU Autotools. Bizarre is the best thing to say, and I am so not used to using any of them. Like I understand Makefiles, and Ant build scripts perfectly. However, all this automatic code generation is making my head spin (not mention my headers).

Well I guess I better get back to hacking… lot of work to do, and so little time. *Climbs back into the cockpit of the mlaren for around lap.*