'data' directory not found no matter how it executed

[Byron]

Thanks for the tool, I thought it would be a good addition to the roster with its focus on statistics.

I installed it with cargo install --git <github url> and when running it, I see this:

The same happens for mezura --version.

I am running MacOS. Maybe it's dependent on configuration files?

[subamanis]

Hello @Byron , thank you for taking the time to report that.

To be honest, I was not aware of this way of downloading and using a crate. Running the cargo install --git <github url> --root <a path> command on my windows machine, creates a bin directory in my specified path, that inside contains just the executable. Running the executable inside that folder, is bound to give you a 'data dir not found' message, because the program expects a data dir, that contains the info for the languages, configurations and logs in the same working directory as the exe.

I am not sure if there is a way to bundle that folder with the exe, but what you can now do, is manually add the data dir provided with the repository, to the same directory of the exe.

As far as macOS is concerned, I have never tested the program there, but there is not reason for me to suspect that it won't work, the only platform specific code is the first line of the main function, that has been accounted for, to only compile on windows.

Let me know how that goes!

[Byron]

Thanks for the swift response.

My recommendation is to use https://crates.io/crates/include_dir and bring the default files directly into the binary.

[subamanis]

Thanks for the recommendation, but I am not sure how much of an option that is, since files in the directory need to be able to be created and changed, even manually from the user, if he wants to add a new language template. I will take a look how other line counting crates are doing it tomorrow.

Meanwhile, if you happen to test the program with the appropriate data folder, you can share the outcome :)

[Byron]

Thanks for the recommendation, but I am not sure how much of an option that is, since files in the directory need to be able to be created and changed, even manually from the user, if he wants to add a new language template.

I agree, but also think it should be possible to make the program start without any assets required in its vincinity. That, or probably adoption will be hampered. There is crates to learn where to place configuration files, which could be used to dump well-known assets into place on first run, which would allow users to change them later.

Users like me would never want to deal with this though, so even dumping files included in the binary onto disk by default would be too much for them. Maybe allow to specify a data directory to load additional files from there.

I will take a look how other line counting crates are doing it tomorrow.

They definitely 'just run'.

I hope you don't mind one more nitpick, but I strongly recommend removing the press any key to exit message on #[cfg(not(windows)) as it's quite surprising and unnecessary learning towards annoying the second or third time around.

[dsully]

+1 to @Byron 's comments. I'm compiling on Linux (Ubuntu) and even running out of the mezura git clone, this error is confusing. You should look at using XDG directories for these data files.

https://github.com/whitequark/rust-xdg is a Rust implementation.

[subamanis]

Guys, running: git clone <repo_url> cd mezura cargo r --release

as it was intended, just works. After that, In my machine I moved the executable and the data dir, to a folder that I have in my path so I can run it from anywhere and it just works, that was the intended workflow. Is that not good enough for some reason?

I hope you don't mind one more nitpick, but I strongly recommend removing the press any key to exit message on #[cfg(not(windows)) as it's quite surprising and unnecessary learning towards annoying the second or third time around.

The reason for the blocking message, is for the user to also be able to run the program by double clicking the executable, without needed a terminal, although this might not make sense, since a regular user would have it on the path and use the terminal to run. I will probably change that, thanks.

[dsully]

FWIW, I went did not install directly from GitHub, but did do a clone followed by a

cargo build --release && cargo install --path .

[vincentdephily]

A combination of including the defaults in the binary and loading user config from a standard dir would be best. For simple CLIs like this, I'm used to be able to cargo install <tool> and run it without further install.

[subamanis]

With the latest release (v1.0.0-beta1), the "data" folder is no longer necessary during runtime, since it is getting baked into the executable at compile time. Running cargo install --git https://github.com/subamanis/mezura --branch main should be enough now for the program to execute globally.

Thanks for your recommendations!

[Byron]

Works for me, thanks a lot!

Something to consider might be to default to using the current working directory if no path is given. For me it was unexpected not to see the output right away, but instead be greeted with a listing of all options. For comparison, see onefetch.

Furthermore, and off-topic, it looks like the commandline argument parsing is not done by clap, the defacto standard, but custom. This means that standards like trying to use -h yields in an error as it tried to us that as a path instead of showing help.