Publish to crates.io about helix HOT 18 CLOSED

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

from helix.

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)

from helix.

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.

from helix.

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

from helix.

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

from helix.

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

from helix.

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?

from helix.

Let's us a symlink then

from helix.

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 ...

from helix.

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

from helix.

Does a symlink work?

from helix.

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

from helix.

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

from helix.

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?

from helix.

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?

from helix.

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

from helix.

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?

from helix.

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

from helix.