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)