cargo-release VS just

My problem with maintaining a changelog during development is it can serve as a source of merge conflicts. Instead, I follow Covnentional Commit style and manually write my changelog entries based on the commits. I have a tool [0] that can show me the relevant commits for a package in my repo and automates the entire release process, including doing sanity checks.

I also feel like releasing from CI is hard, especially if you have multiple packages in a repo [1], including

- You can't as easily introspect the process

- You can't as easily recover from failure

- Getting a lot of the nuance right, like handling releases concurrent to merging of PRs, is difficult

- When the workflow is an ever-present "release PR" that you merge when ready has issues with selecting which packages to release and at what version

I have been considering making a tool to generate changelogs from fragments. Been keeping notes at https://github.com/epage/epage.github.io/issues/23

[0]: https://github.com/crate-ci/cargo-release

[1]: https://github.com/MarcoIeni/release-plz/discussions/1019

You should combine step 1 and 2 with CI. Just tag a version in your git, push to remote and have CI auto build a release for you.

Use github actions or other setup for other backends.

Or go nuts with cargo-release.

https://github.com/crate-ci/cargo-release

https://github.com/cargo-bins/release-pr

tools like cargo-release

Just to check, are you aware of cargo-edit's cargo-set-version or cargo-release?

I released my first crate that provides a derive macro to easily obtain a name of a current variant in an enum as a string. I did it mostly to learn about procedural macros and the process of releasing a crate. I then found out there is strum which does this and much more. Nonetheless, I learned a lot and I found couple of nice tools like ```cargo-release and git-cliff.

I'll note there is an issue in the cargo-release repo where this kind of workflow is wanted. https://github.com/crate-ci/cargo-release/issues/119

cargo-release is on about the same level of features used

cargo-release automates the release process for your crate. For example, with clap, all I do is add entries to the CHANGELOG and run cargo release patch and cargo-release takes care of updating files, publishing to crates.io, tagging, and pushing.

Yes, developers from all three tools were sharing ideas with each other recently

I use `just` - https://github.com/casey/just and have a `docs` task. That runs a bash script that does all the heavy lifting (python install, and so on).

Though given all the chatter on here in the last couple of weeks, I'd migrate some the python work to `uvx` and that would make things simpler again.

I'm don't know if doxygen easily supports 'incremental' builds for your use case. I've never really found completely re-building docs for my modest repos a bottleneck.

Well, I don't use makefiles to deploy software with Rust. I also have never used lex or yacc, but I bet there are similar tools in the ecosystem, or wrappers for those. That would obviate what I will offer below.

Often a new language in a project would define an application boundary. So those would be different containers or services. I may deploy via container images, or an OS specific installer, etc. If we aren't crossing an application boundary I may use FFI. Sometimes I use https://rust-lang.github.io/rust-bindgen/ to smooth that over for C dependencies. There is also a nice concept called a build.rs file: https://doc.rust-lang.org/cargo/reference/build-script-examp.... There's also tools like: https://github.com/casey/just and https://sagiegurari.github.io/cargo-make/

I rarely use multiple languages with Rust. A lot of interpreted languages have bindings through crates and can go in to a project through Cargo. If it involves JS/TS on desktop, I'm usually using Tauri for that. Guess it depends on the system?

Hopefully that helps. You can also still use a Makefile if you want I just haven't dealt with one in a long time.

I thought this was common knowledge and that it became even easier after Docker became a thing?

Mocks are wishful thinking incarnate most of the time, though here and there they are absolutely needed (like 3rd party APIs without sandbox environments, or quite expensive API, or most of the time: both).

Just pick a task runner -- I use just[0] -- and make a task that brings up both Docker and your containers, then run your test task, done. Sure it's a bit fiddly the first time around but I've seen juniors go beyond that in a day maximum and then your tests actually work with the real world 99% of the time.

Mocks in general are rarely worth it, the DB ones: 10x so.

[0] https://github.com/casey/just

just, stores tasks in a file similar to Makefile format, has CLI completion support and loads .env files

'Just' too was simple at the beginning [1], but with time and usage things always become more complex that some script you do for your own specific use-case.

[1]: https://github.com/casey/just/tree/v0.2.23

Justfile[0] was a more familiar makefiles replacement for me

[0]: https://github.com/casey/just

Benefit is you can just type the command, no need to prepend pyqwe or anything.

See also justfile for a non-python specific tool https://github.com/casey/just

This is an interesting approach. These days I have completely switched to just[0] tool for similar use case.

[0]: https://github.com/casey/just

# Palindrome project Project used to explain my view on a django project architecture ## Tools, libs, etc. Some time related files. Versions on Poetry. - [Python](https://www.python.org/) Programming languange - [django-environ](https://django-environ.readthedocs.io) Manage .envs in Django - [Poetry](https://python-poetry.org/) Python packaging and dependency management - poetry.lock - pyproject.toml - [Django](https://www.djangoproject.com/) Web framework written in Python - [Docker](https://www.docker.com/) Manage containers for dev environment - compose.yaml - compose/dev/Dockerfile - compose/dev/start - .env - [Just](https://just.systems/) encapsulate commands for easier use - justfile ## Dev environment setup 1. Install Just, Docker and Poetry(opcional). 2. Copy .env.example to .env, no need for edtion. 3. Certified that docker is up and running 4. `$ just build` ## Run the server for development 1. Certified that docker is up and running 2. `$ just runserver` You can access on http://0.0.0.0:8000/