Skip to content

Conversation

matthiasbeyer
Copy link

This is needed for packaging and it is also normal to add the lockfile, so lets do it.

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
@schungx
Copy link
Collaborator

schungx commented Aug 17, 2025

Wouldn't the lock file be regenerated upon build if it is not included?

@matthiasbeyer
Copy link
Author

The lock file, as the name suggests, is for locking dependencies. If it is not included, a build is not reproducible for example.

For more rationale, look here: https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control

@schungx
Copy link
Collaborator

schungx commented Aug 18, 2025

The lock file, as the name suggests, is for locking dependencies. If it is not included, a build is not reproducible for example.

I understand the concept of keeping the lock file in version control, but I am not convinced that it is absolutely necessary. cargo install will always refresh the dependencies so the lock file is not used. In a perfect world, new dependencies should not break builds, so there is no need to keep a "last-good" version of the lock file.

And any "last-good" version will likely be outdated very quickly, and novice users building it themselves may not remember to do a cargo update, so it always gets built with old crate versions.

@matthiasbeyer
Copy link
Author

In this case, this package will not be included in any distros.

@schungx
Copy link
Collaborator

schungx commented Aug 18, 2025

In this case, this package will not be included in any distros.

I don't know enough about this to comment... I understand you mean that the distro author would want a reproducible build?

Anyhow, this crate is work-in-progress, and is not release-ready. Those who uses it are likely to be cloning it locally and building themselves. We can worry about packaging it when it is done...

@matthiasbeyer
Copy link
Author

matthiasbeyer commented Aug 18, 2025

understand you mean that the distro author would want a reproducible build?

Yes

We can worry about packaging it when it is done...

I'll suggest to close the nixpkgs PR then.

@schungx
Copy link
Collaborator

schungx commented Aug 19, 2025

I'll suggest to close the nixpkgs PR then.

Not sure what that is... Can you elaborate?

I admit I didn't write this repo and not familiar with it.

@niclashoyer
Copy link

@matthiasbeyer @schungx

just stumbled on this while trying to integrate (and use) rhai in one of my rust projects.

To elaborate: there is (was) an open PR by @yzhou216 to package rhai-lsp for nixos (NixOS/nixpkgs#434339) and Matthias reached out to let you know that the Cargo.lock file is missing.

Without the lock file it is not possible to reliably reproduce what the author(s) of this crate used or intended to have when building the crate. So it actually is common practice to just commit it. While I must admit that this project is not in a good shape, it would nevertheless be good if we could get this going again, as there seems to be still interest in rhai and also this lsp.

so lets do it.

🎸

@schungx
Copy link
Collaborator

schungx commented Aug 22, 2025

Yes, I agree that we should get someone to pick up the LSP repo. Users have been asking for it and I don't know enough myself to keep it going.

Would appreciate any interest in restarting this development.

As for packaging for a distro, I am quite sure this repo is so outdated and feature lacking that it won't be a good idea...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants