Any plan about publishing in crates.io?

[topazus]

There are many useful and awesome libraries or applications in the The Rust community’s crate registry
Browse All Crates, and it has benefits of publishing to crates.io.

ref: https://doc.rust-lang.org/cargo/reference/publishing.html

[jpgrayson]

I have not published StGit to crates.io for the same reasons I never published the Python implementation pypi.org, namely:

• StGit is an application, not a library and those platforms are most useful and geared for libraries.
• The implementation language of StGit is meant to be an implementation detail for StGit users whereas crates.io and pypi.org are decidedly language-specific package indexes.
• In addition to the stg executable, StGit also ships with man pages, contrib scripts, and a few other goodies. Neither platform has mechanisms for installing those extra things, so an installation of StGit from crates.io would be sub-standard compared to how it is packaged in general-purpose software distributions such as brew, Arch, etc.

The primary reason I would consider having StGit on crates.io is to avoid someone else squatting the name. I note that there is already an unrelated stg crate, but not yet a stgit crate.

I'm open to counter arguments on this topic. I'll need some convincing...

[proski]

I was writing a bug about StGit not being on crates.io, then I decided to search for prior discussions - and here it is!

Reasons for publishing StGit:

• Squatting risk - I don't want some clueless person to take "stgit" for an unrelated project or for a poor unmaintained fork.
• Linux distros are slow to switch to the Rust version. Even the upcoming Ubuntu plans packaging 0.19. https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=stgit
• As a software developer (StGit users are mostly software developers), I trust language specific package repositories more than generic third-party repositories (snap, flathub).
• crates.io is language specific, but not OS specific. I like installing tools in a consistent way on different OSes. That's why I prefer crates.io over Homebrew if both have the package.
• There are already two tools I install from crates.io on all my development systems, namely ripgrep and fd-find. I've been a ripgrep user long before I started coding in Rust.
• If there are limitations with packaging documentation, please work with the Rust community, they have to be fixed.
• Contrib scripts and other goodies can stay in GitHub, I won't look for them in the installed package.

[jpgrayson]

I appreciate this contribution to the conversation. I'm thinking about it.

If there are limitations with packaging documentation, please work with the Rust community, they have to be fixed.

StGit's man pages are generated. The generation process uses the stg executable. It also uses additional documentation-only dependencies such as asciidoc and xmlto. These documentation build complications are sufficiently outside the scope of cargo that I would not expect that team to be receptive to accomodating StGit's needs.

Linux distros are slow to switch to the Rust version. Even the upcoming Ubuntu plans packaging 0.19.

That Debian neither updates its stgit package nor drops it from their distro frustrates me. Either would be preferable versus continued shipment of StGit 0.19.

I don't hold out much hope that either the Debian/Ubuntu or Fedora/RedHat ecosystems will package StGit 2.x anytime soon. AFAIK, both are taking the approach that each of a Rust package's transient dependencies must come from an rpm/deb package. For StGit, that's over 100 other crates. Also, Debian seems to insist on using very old Rust toolchains which compounds the problem further. It would be more technically feasible for them to package StGit 1.5 (the last Python release), but nonetheless StGit doesn't seem to have the attention of any packagers from that world.

On this front, we are now publishing both deb and rpm packages with StGit releases. E.g. https://github.com/stacked-git/stgit/releases/tag/v2.3.0. These packages contain statically linked stg executables and may thus be installed on a wide spectrum of rpm and deb-based distributions. My hope is that this provides a reasonable path for StGit users in those deb/rpm ecosystems.

[proski]

I ended up with installing stgit using Nix. I track some other packages through Nix, so it's convenient to update them all at once by running nix profile upgrade '.*' once in a while. I would still prefer to use crates.io, as nixpkgs is sometimes slow to update software (not stgit, thankfully), whereas packages on crates.io are typically in sync with GitHub releases.

By the way, Stylua (a formatter for Lua) is available both through crates.io and Nix. Stylua is obviously not a Rust tool, but it doesn't stop them from using all available channels to get their releases to the users. Likewise, nixpkgs-fmt, the semi-official Nix formatter in on crates.io.

[jpgrayson]

Okay, @proski, you've persisted long enough. I've gone and done it.

https://crates.io/crates/stgit

I would appreciate you testing it out. The README.md might benefit from some updates now that it shows up on crates.io. There are also keywords and categories that should maybe be added to the Cargo.toml file. I'd appreciate any help you're willing to give to make StGit more discoverable on crates.io.

I will look into adding something to the CI to auto-publish new versions of this crate whenever a new StGit tag is pushed.

[proski]

Thank you! I really appreciate it. I was able to install StGit 2.4.4 with cargo install stgit, everything is good.

I agree that README.md needed some updates.

Perhaps StGit should be added to the Development tools category, mostly because it belongs there. I don't think it would make StGit much easier to discover.