❤️ Help publish lychee for common platforms

[mre]

Introduction

lychee is getting more mature and we'd like to share the future v1 with a broader audience.
For that we need an easy way to install the binary.

Package Managers

• cargo install (automatically publish on crates.io with github action) (see Publish releases on crates.io #65)
• Docker Hub (see Publish images to Docker Hub #40 and Add Docker image #40 #52)
• Binary releases on Github
• Github Actions marketplace
• cargo binstall
• AUR (Arch Linux)
• Alpine Linux
• pkg (FreeBSD)
• Homebrew for macOS (Instructions, Github action)
• NixOS
• Termux
• scoop for Windows
• winget (Windows Package manager)
• Chocolatey for Windows (in progress)
• cargo quickinstall
• apt (Debian/Ubuntu) (see https://bugs.debian.org/993913) ¹
• rpm (Fedora/RedHat)
• emerge (Gentoo)
• snap/flatpak

Preferably, all of our packages should have versions for these CPU architectures:
x86_64, arm and aarch64 (64-bit ARM)

(This list is probably incomplete and should be extended.)

Language Bindings

• NPM (JavaScript bindings using Neon)
• pip (Python Bindings using pyo3)

How to contribute

Please pick one of the above targets and create a pull request.

Inspiration:

• Binary releases on GitHub: https://github.com/BurntSushi/ripgrep/blob/master/.github/workflows/release.yml
• APT package: https://github.com/sharkdp/bat/blob/master/.github/workflows/CICD.yml
• Chocolatey: https://github.com/marketplace/actions/chocolatey-action

Footnotes

1. Maybe using cargo-deb ↩

[pawroman]

I'm happy to contribute an Arch Linux AUR package 👍

[pawroman]

General remark: arch-wise, we could consider publishing binaries for x86_64, arm and aarch64 (64-bit ARM).

I'm sure there would be at least some ARM users.

[mre]

Sure! That would be great. Updated the list accordingly.

[pawroman]

Sorry for confusion, by this

General remark: arch-wise, we could consider publishing binaries for x86_64, arm and aarch64 (64-bit ARM).

I meant that all of our packages should have versions for these CPU architectures. This includes Docker, binaries published on GitHub and other binary packages.

Arch Linux is just Arch Linux :)

[mre]

Noted. Updated the list accordingly. 👍

[mre]

Talked to @pizzamig and he'd be willing to support us with the FreeBSD package. Thanks!

[mre]

Hum... working on binary releases but it seems to be harder than expected.
Developing this on a fork as I never get those CI builds right on first try. 😆

Current pipeline:
https://github.com/mre-early-access/lychee/blob/master/.github/workflows/release.yml

Last build:
https://github.com/mre-early-access/lychee/runs/1500158899?check_suite_focus=true

If someone wants to hack on this, go ahead.

[mre]

Binary releases are done. 🥳

[mre]

lychee Github action: https://github.com/marketplace/actions/lychee-link-checker-action

[alebcay]

Hi there 👋, I've submitted a pull request for including lychee in the Homebrew core repository at Homebrew/homebrew-core#70216.

Just wanted to verify one thing - is lychee licensed under either of (at the user's choice) Apache-2.0 or MIT? This was my understanding although I could not find it explicitly stated anywhere.

[mre]

Oh that's so nice of you @alebcay. 🥳 Let's hope it gets accepted. 🤞

Just wanted to verify one thing - is lychee licensed under either of (at the user's choice) Apache-2.0 or MIT? This was my understanding although I could not find it explicitly stated anywhere.

Yes, exactly. I've added a paragraph to the end of the README.md now to clarify that.

[mre]

Looks like the build failed because ring couldn't build:

error: unknown target triple 'unknown-apple-macosx11.0.0', please use -triple or -arch

That seems to be an issue with macOS Big Sur... 🤔 I wonder if that's supported by ring already.

[mre]

Some hints here: ogham/exa#780

[mre]

Homebrew/homebrew-core#68301

[orhun]

lychee is available in Arch Linux community repository: https://archlinux.org/packages/community/x86_64/lychee-link-checker/

[pawroman]

Issues/PRs blocking homebrew:

• Publish new release softprops/hubcaps#288
• Update fast-socks5 dependency async-email/async-smtp#36 (needed by check-if-email-exists)

[fauust]

Hi! I am happy to help on the Debian/Ubuntu part. But I am not sure about what you want.

Do you want to produce deb packages in CI and make them available as assets (isn't the bin tar sufficient?) or are you interested in having lychee available directly on Debian/Ubuntu repositories?

[mre]

We'd love to have lychee available on Debian/Ubuntu repositories directly.

apt get install lychee

would be so lit.

[mre]

And thanks for offering your help. Any support here is highly appreciated.

[fauust]

Ok, but before apt-get install lychee is possible, lot (lot) needs to be done, Debian packaging represent lots of work...

Anyway, as in your bat example, does it make sense to propose .deb files as assets? Also, for debian/ubuntu packaging, the first thing that comes to my mind and that is missing is a manual page.

[mre]

Okay a manpage should be doable. Think clap has a generator of some sorts for that -- at least an unofficial one.
Creating self-hosted debian packages would be an option for now, too. 👍

[mre]

Thanks for looking into that.

[san-slysz]

Hi everyone,
Have-we consider making lychee available on the npm registry? Could we add this one to the list?
npm install lychee --save-dev

[mre]

Yes, we discussed that in #420.
I'll add it to the list. I think we can use Neon to generate the bindings. This could start as a separate project in a separate repo, so if anyone wants to give it a try, feel free. I want to tackle this after 1.0, probably, but maybe someone finds the time to experiment with it and report back.

[mre]

We need someone that can package lychee for Windows with Chocolatey and winget? Any takers? 😊

[lebensterben]

@mre
We may also add lychee to https://github.com/alsuren/cargo-quickinstall

[mre]

Yeah that's a great idea. Let me add that to the list

[soredake]

chocolatey-community/chocolatey-package-requests#1391
microsoft/winget-pkgs#91395

[mre]

Amazing @soredake. Thanks so much for pushing this forward.

[mre]

Winget seems to have been merged! microsoft/winget-pkgs#91422

[mre]

Worked like a charm.

Needed to update to the latest winget version. With the old version (1.2) I got a confusing error message at first:

> winget install lychee
winget 0x80070032 : The request is not supported.

Updated winget through the Microsoft Store by updating "App Installer", which contains winget.
Then from an administrator power shell:

PS C:\Windows\system32> winget -v
v1.3.2691

PS C:\Windows\system32> winget install lychee
Found lychee [lycheeverse.lychee] Version 0.10.3
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/lycheeverse/lychee/releases/download/v0.10.3/lychee-v0.10.3-windows-x86_64.exe
  ██████████████████████████████  12.7 MB / 12.7 MB
Successfully verified installer hash
Starting package install...
Overwriting existing file: C:\Users\mendler\AppData\Local\Microsoft\WinGet\Links\lychee.exe
Successfully installed

Closed and reopened the shell and lychee was in my PATH and worked as expected:

PS C:\Windows\system32> Get-Command lychee

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     lychee.exe                                         0.0.0.0    C:\Users\mendler\AppData\Local\Microsoft\WinGet\Links\lychee.exe

PS C:\Windows\system32>  lychee ...

Thanks a lot @soredake.

[aj-stein-nist]

Is asdf worth considering? I like it a great deal. I can help work on that if and send back info if you are interested.

https://github.com/asdf-vm/

[lebensterben]

asdf is not a package system designed for distributing packages. it's only designed as a version manager for programming language toolchains.

the entire asdf-plugin ecosystem is abusing it.

[aj-stein-nist]

asdf is not a package system designed for distributing packages. it's only designed as a version manager for programming language toolchains.

the entire asdf-plugin ecosystem is abusing it.

So I guess I can take that as a no vote. No worries, I just thought it would be usefully for testing parallel versions simultaneously without installing (some plugins existing to manage binaries that are not strictly for programming language runtimes). It would have been useful for testing issue 1020, but no worries.

[mre]

Yeah, I have similar feelings about asdf as @lebensterben. Always saw it as a version manager for programming languages — not programs. In any case, thanks for the suggestion @aj-stein-nist.

[aj-stein-nist]

Yeah, I have similar feelings about asdf as @lebensterben. Always saw it as a version manager for programming languages — not programs. In any case, thanks for the suggestion @aj-stein-nist.

All good. I presume you do not have objections to me making an asdf plugin do you? I can always make one and not publish it, but it is not hard to do and I can't stop others. Thanks again to all of you, I am a big fan of this project, keep up the good work.

[mre]

Of course. Go ahead. 👍 Happy hacking.

[echoix]

I also see cargo-binstall as an easy target, since multiple binaries for multiple target triplets are already in the GitHub releases (it is really useful to have so many, especially for musl and arm, where compiling on arm devices can be long!).
Adding support for it is a matter of adding metadata in the Cargo.toml file, like described in :
https://github.com/cargo-bins/cargo-binstall/blob/main/SUPPORT.md

Cargo binstall helps to install binaries by simply downloading them from the releases, following the correct file naming for their platform, with a fallback on quickinstall, and a fallback of simply installing with cargo if nothing better was available.

[orhun]

Added cargo-binstall metadata in #1073

[mre]

Awesome job! cargo-binstall support got merged now. 🥳

[soredake]

Can snapcraft / flatpak be added to list?

[mre]

Sure, done