Cargo cook subcommand

help
1

Hello everyone. This is some kind of an advertisement here. I have started a project called cargo cook. I need a help in implementing it. If anyone will find the idea of it useful - I will appreciate any contributions to it.

Let me explain why I have made it and what should it do in my opinion. After building a crate you have a produced binary file (or a library). You may want to upload it somewhere for further downloading and use. For example, you have made a game called rustquake in pure Rust. You want to release it so you compile it in release mode with all optimizations and then you may want to upload the binary (and some other files like config files, libraries, images, shaders, etc) somewhere. It would also be nice to compress all of this. So, you manually create an archive, for example, rustquake-0.1.1.tar.gz where you manually put all the files you need. Then you go to your server, put the archive in some folder which your web-server knows about manually again. This is a lot of routine work. So, personally I need this and found (maybe I looked very bad, I don't know) that there is no such way of doing this. So I decided to do it by myself. I don't know cargo, it does not even has a normal documentation for creating subcommands, so I have done it in a newbie way. Also, I don't know rust very good but I feel it is the future, I love it.

So, at this moment, the cargo cook is doing the following: grabs a produced binary file from target/release directory (specified in Cargo.toml), puts it into tar container and creates a md5 has for it.

The goals I want to reach are:

  1. The crate can rename your target file before packaging. For example, you have rust-quake binary in your target/release folder but cooking packages it as rq-0.1.0 for example.

  2. Executing pre-cook and post-cook scripts.

  3. The cooking process must create archives and hashes for as much types as possible. For example, I want to extend the containers support to [zip, 7z, rar, tar.gz, tar.bzip2, lzma] and hashes to [md5, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum].

  4. The cooking process may also package specified ingredients by a regular expression into desired folder. For example, you have an src/images subdirectory with *.jpg and *.bmp and you want to package them in the following way:

     *.jpg => archive/jpg_images/
 *.bmp => archive/bmp_images

  5. The cooking process must have a possibility to include dependencies into the package. I don't know anything about this yet, I am coming from C++ where you may distribute your project with the libraries you need. So, maybe this would be helpful too here.

  6. The cargo cook must have a way to upload packages. The supported destinations must be: http, ftp, ssh, file system.

The roadmap is defined as an issue here.

So, basically, that is all I have for now. I am waiting for any feedback here.

2

There certainly is a demand for post-build scripts in Cargo: Post-build script execution · Issue #545 · rust-lang/cargo · GitHub

Although everyone has slightly different needs here.

3

I recommend defaulting to SHA-256, MD5 and SHA1 have been broken and should be phased out.

4

SHA-256 is definitely the go-to option, but MD5 is still fine for integrity-checking, just not for most cryptographic purposes.

5

The week has passed and here is what I have done:

  1. Uploading files through SSH with executing a user script after.
  2. Performing FS-copy.
  3. 3 hash algorithms are implemented by now: md5, sha256 and sha512.
  4. tar.bzip2 support is implemented.
  5. Ingredients were implemented.

Personally I use it for my projects already.

6

You really, seriously, don't want to implement or use md5. Stick to sha512_256t or better.

Regardless, great work, thanks!

7

You've missed a golden opportunity here to name this "cargo pack" instead of "cook".