❤️ Help publish lychee for common platforms about lychee HOT 50 OPEN

Added cargo-binstall metadata in #1073

from lychee.

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

from lychee.

Great! Can you create a PR to mention that in the README? ✨

See #274

from lychee.

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.

from lychee.

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

from lychee.

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.

from lychee.

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

apt get install lychee

would be so lit.

from lychee.

@alebcay, thanks so much for adding lychee to homebrew.

brew install lychee

works as expected. ✌️

from lychee.

Thanks!

from lychee.

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

Hey @mre!
I may have some spare time in the next weeks to look at Debian packaging.

So, I have some questions to understand better in which direction you want to go:

• what about creating a debian/ directory with all the necessary stuff, wouldn't that be easier to maintain than having everything generated in the CI (like in the bat example you are pointing to)?
• do you have any reason why you prefer cargo-deb over debcargo (I do not have experience with those tools BTW)?

Cheers!

from lychee.

@mre I am still not sure about the best solution. bat is packaged into Debian so I may contact the maintainer to understand what workflow he use and then decide based on that.

My idea is to reduce as much as possible the diff (or the sync mechanism) between upstream and downstream Debian/Ubuntu packaging.

from lychee.

Working on another packaging project (Go), I found out where bat is packaged for Debian:
https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master/src/bat/debian

GIven the number of Rust packages that seems to be packaged this way, I believe this is the way to go:
https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master/src/

So, next step is to understand better the workflow...

from lychee.

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

from lychee.

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

from lychee.

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.

from lychee.

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.

from lychee.

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.

from lychee.

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

from lychee.

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

from lychee.

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.

from lychee.

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

from lychee.

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 :)

from lychee.

Noted. Updated the list accordingly. 👍

from lychee.

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.

from lychee.

Binary releases are done. 🥳

from lychee.

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

from lychee.

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.

from lychee.

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.

from lychee.

Some hints here: ogham/exa#780

from lychee.

Homebrew/homebrew-core#68301

from lychee.

Issues/PRs blocking homebrew:

• softprops/hubcaps#288
• async-email/async-smtp#36 (needed by check-if-email-exists)

from lychee.

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?

from lychee.

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

from lychee.

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.

from lychee.

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

from lychee.

I have added lychee for Termux, see termux/termux-packages#7050 🚀🚀🎉

from lychee.

Great! Can you create a PR to mention that in the README? ✨

from lychee.

Thanks for helping out. debcargo looks nice. Let's try it!
I'm fine with adding a debian subfolder. Reading through the debcargo docs, we might only need one toml file anyway, which would be sweet.

from lychee.

bat is packaged into Debian so I may contact the maintainer to understand what workflow he use and then decide based on that.

Sounds like a good idea. Thanks for looking into this.
Also perhaps you can give debcargo a spin and see what output it produces to have a starting point.

from lychee.

Thanks for looking into that.

from lychee.

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

from lychee.

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

from lychee.

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

from lychee.

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

from lychee.

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

from lychee.

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.

from lychee.

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/

from lychee.

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.

from lychee.

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.

from lychee.

Of course. Go ahead. 👍 Happy hacking.

from lychee.