Consider treating nix/nixos as a first class citizen. The reasoning might be a touch different to what you might expect.

[Ben-PH]

Sorry for the clickbait title, but I feel it might actually be warranted: I'm less interested in nixos support from a "add it to the nix ecosystem" perspective, and more from the "In order to cater to nix/nixos, it's just easier to do things properly and without shortcuts" I thought that distinction might be a novel concept.

Consider my thoughts on Rust. As a language, it drives you in a direction where lifetimes are addressed, logic is encapsulated at the type level, no shortcuts taken, etc.. I found that short cut habits I developed in other languages become pain points in Rust. It compelled me to do things cleanly.

My limited experience with robotics ecosystems so far has me convinced that a sense of "do it right. do it clean. don't take shortcuts that make the ecosystem messy" isn't so prevelant. I don't believe it has to be that way. I feel like catering to the expectations of nix/nixos will help with that.

An e.g.: The installation of dora-cli

The idiomatic install-from-source is a git clone ... then cargo install. With dora, instead of cargo install, it's a package build followed by adding the compiled binary to your PATH env. This is a personal hot-take, but this feels like a shortcut that makes this ecosystem feel a bit... "unclean". (sorry for the negativity).

My thinking is that if the expectations of nix/nixos were catered to from the beginning, it would have surfaced this shortcut, and the project would have been forced to confront it and find a "clean" solution.

This is just one thing, but it all adds up, and the risk is for it to reach a point where using dora outside of docker, or a VM instance is an uncomfortable proposition.

In the long run, what I'd love to see is a dev workflow that might look like this:

sudo apt install nix # just the once
mkdir dora_thing && cd dora_thing
nix develop github:dora-rs/dora

or:

git clone [email protected]:dora-rs/dora-flake.git dora_thing && cd dora_thing
nix develop

Either of these would, in theory, set everything up to get to work. No VM, Docker, etc needed.

but here is the key idea in my mind

The benefit to the above workflow isn't in supporting nix/nixos, it's that it creates guardrails against taking the dora project in a direction where you need to isolate its use, such as with Docker or a VM. If you start relying on things like where in path your project root is, persistent environment variables, etc. This makes supporting nix complicated, and prompts you to ask yourself "is there a better way to do this?"

[haixuanTao]

I understand what you're saying.

To be very honest, I really have 0 experience with nix so I don't have any clue on this would work.

I think we should split the development aspect and the usage aspect.

For development of dora ( the project )

dora is 100% a rust project meaning that everything is managed by cargo.

So basically, we want to use it with:

cargo build -p dora-cli ( or other dora library) 
cargo test -p dora-cli
cargo run --example ...
...

And normally, finger crossed, everything should just compile.

In this step, there is no PATH env variable required and everything is following the cargo guideline.

tl;dr: We want to prioritise cargo for clean development

For usage

In a perfect world, everyone would use:

cargo install dora-cli ...

but...

not possible...

so...

We have to rely on pre-compiled binary shipped on github, but need to be in PATH so that people can use it without having to remember the full path everytime.

Note, that this is what most rust project do...

And, I agree, that it could be cleaner... better...

Like, putting it in apt or brew or what not.

Just don't know how and don't really have the mind bandwith to do it...

But ultimately yes, it should be cleaner...

Is Nix the solution

I think nix is great but if you already know nix, and unfortunately, i don't think most robotist are familiar with it, so, it's hard for me to make it a first class citizen :S

[Ben-PH]

What's getting in the way of making it available through cargo install?

[Ben-PH]

To be very honest, I really have 0 experience with nix so I don't have any clue on this would work.

I'm very new to nix as well. very much in the "nix is a hammer, and everything feels like a nail", so I could just be talking out of my @$$

for dev of dora

Okay, cool. I now see that this is not where the ecosystem could get "dirty", and this post is out of scope for that aspect.

In a perfect world, everyone would use [...]

agreed.

And, I agree, that it could be cleaner... better...

I'm glad we have established where our thoughts are, and it appears that we are on the same page.

but... not possible... [...]

I'd like to get to the bottom of that (for the sake of my own curiosity). Any pointers as to why?

Is Nix the solution

For me, the problem scope where this question is most relevant is in providing guard-rails in keeping things clean and straigt forward when it comes to usage. My thinking is as follows:

1. A use case comes up
2. the dora project works on putting together a nixey way of supporting this use case
3. the initial intended approach is difficult to implement nix-support for
4. this discovery surfaces what makes this approach problematic
5. The approach is reworked so as it is straight forward to implement for nix
6. The reworked approach is now "clean" for non-nix environments, preventing the need to recommend the use of containers.

To use Rust as a parallel:

1. A thing that needs to be implemented comes up
2. An approach to a particular implementation in Rust is attempted
3. The initial intended approach is made very painful due to rusts rule-sets, guard-rails, etc.
4. this discovery surfaces aspects of this approach that are problematic.
5. the approach is reworked to be "idiomatic Rust"
6. the reworked approach could now inform you how to write this in any other language, and you would be more protected from memory issues, pathological GC scenarios, etc.

[phil-opp]

What's getting in the way of making it available through cargo install?

It is already available through cargo install dora-cli. No additional steps required.

In a perfect world, everyone would use:

cargo install dora-cli ...

I think what @haixuanTao meant with this is that there are some people who don't have Rust/Cargo installed. We don't want to force everyone to install a Rust toolchain first, so we provide an install.sh script as an alternative installation method. This method might be easier for people that want to use dora only with Python.