Publish to crates.io

[mfrw]

Not sure if this is the right place to request. If this is not the right place, please redirect me to the correct one.

Let's publish this to crates.io, so that we can do something like
cargo install helix-editor given helix is already taken.

[archseer]

I've considered this, but the editor still needs the runtime/ queries folder to be downloaded and placed somewhere. Would we be able to distribute this alongside it?

[sudormrfbin]

Since #102 is merged, can't this is done now ?

[pickfire]

Discussed this in matrix yesterday. This is due to helix not specifying the version within the crates, could be done after we do that.

pickfire
How do you cut releases now?
Can you please push the releases to crates.io? So someone could do cargo install helix-term.
Or we can suggest those from crates.io to use the embed_runtime feature.
Blaž
there was an issue with pushing to crates.io directly since the crates refer to each other via relative paths
haven't looked into what the right setup is yet
pickfire
Put the version with the path?
https://github.com/BurntSushi/ripgrep/blob/master/crates/cli/Cargo.toml#L19

woshilapin

Blaž
ah I see, so the version and the path can co-exist

Yes they can. Actually, from what I understand in the documentation, path will always be used, except when publish. You can look at the last paragraph of this section of the documentation.
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies

[CBenoit]

Quick heads-up, for cargo to actually package files into the crate to be published on crates.io, said files need to be under the same root folder.
Currently, we are blocked by:

• /languages.toml included in helix-term/,
• /theme.toml included in helix-view/,
• and /runtime/ included in helix-core/.

Possible changes:

• move files under the same root as the including crate,
• create a root package including everything,
• create a new "resource" crate under which we move and include everything,
• or, create (a) new repository(ies) that we clone as appropriate using build.rs

(we could also just forget about publishing on crates.io)

cc @archseer

[archseer]

Does a symlink work?

[CBenoit]

It should works, at least on Linux (Windows appears to have an open issue)

[archseer]

I think that's enough, since we just need to package it once on any architecture.

[archseer]

Let's us a symlink then

[tjapro]

Hello, I'm looking foward to see this project completely at crates.io!
I'm preparing this program to be ready to install at fedora OS via dnf, but I cannot go further, because the crates are empty ...

[archseer]

With the grammars now being split out and compiled into the runtime folder, I don't think we can package this easily on crates.io. Given that crates.io is primarily for distributing code, I wonder if it really makes sense to distribute helix there.

Could you just package the github binary releases for now? It's what all the other distro packages are doing.

[archseer]

I don't think it makes much sense for us to package on crates.io because of the runtime/ requirements.

[baarkerlounger]

It looks like publishing to crates.io is a pre-requisite for packaging helix for debian apt repositories. In light of that would you consider re-opening this?

[dead10ck]

It looks like publishing to crates.io is a pre-requisite for packaging helix for debian apt repositories. In light of that would you consider re-opening this?

Could you elaborate? Why is it a prerequisite?

[baarkerlounger]

All of the Debian rust team's packaging tooling is built around crates.io.

[dead10ck]

All of the Debian rust team's packaging tooling is built around crates.io.

How do you mean? How would helix being on crates.io make building any easier than pulling from GitHub?

[archseer]

I think Debian packaging revolves around crates (each crate getting one package, same as fedora and absolutely unsustainable for binaries with a lot of dependencies), and not about crates.io. We do use crates to build helix, we just don't publish to crates.io

[brizzbuzz]

Yea, hope team reconsiders this, I would like to be able to install helix using cargo binstall https://github.com/cargo-bins/cargo-binstall

[tgross35]

I don't think it makes much sense for us to package on crates.io because of the runtime/ requirements.

Binstall would be nice but otherwise, a hx install/hx uninstall/hx update command that configures these files is how some tools work around this. That could be nice too since it provides a way to update grammars or other contrib/runtime files even if the main install can't be updated (such as a repository being slow to update)

[theoparis]

I was looking to be able to guix import the helix crate on a Guix system, only to find out that helix-term is not being updated on crates.io and this issue is closed 😕

Also, it seems like the helix-term crate on crates.io might be in violation of the crates.io usage policy.

exists only to reserve a name for a prolonged period of time (often called "name squatting") without having any genuine functionality, purpose, or significant development activity on the corresponding repository

[CBenoit]

Also, it seems like the helix-term crate on crates.io might be in violation of the crates.io usage policy.

exists only to reserve a name for a prolonged period of time (often called "name squatting") without having any genuine functionality, purpose, or significant development activity on the corresponding repository

This crate is not in violation of the crates.io usage policy, and here’s why:

• "significant development activity on the corresponding repository" → The corresponding repository demonstrates clear and significant development activity.
• "purpose" → The existence of the crate on crates.io fulfills a critical purpose: it prevents name squatting or, worse, misuse by malicious actors who could exploit the name of a popular project. By securing this name, the Helix project safeguards its community.
• The very notion of name squatting implies a third-party claiming a name unfairly. However, in this case, the Helix project itself owns and manages the crate. There is no external entity being disadvantaged or deprived of rightful ownership.