feat: Lower the required rust version to 1.66.1 about eza

[cafkafk]

I mean it would be a lot of work to create feature gates for e.g. having older versions on lazy_static and newer versions on once_lock, and it would probably be terribly brittle. And we're pulled in both directions all the time, which is why we settled for 1.70 which was used by ripgrep, fd, and bat IIRC, all both similar tools. I imagine debian supports one of those, and I wonder how exactly, that precedent might help guide a solution here.

[dsommers]

Just to clarify on the Debian/Ubuntu requirement as well. I see there is a third-party repo available. But that repository does not provide any source package of the exa build. So it's really hard to look into how the package is built. I'm not fond of running tools from binary-only packages, which may be run as root (where eza would also be useful). That is essentially a security risk to not be able to verify the package content.

Being able to build eza yourself from source gives a chance to at least validate the binary in the packaged version against the locally built one - since rust applications should be able to provide reproducible builds.

Right now, with a third-party repository, there is a potential risk with supply chain attacks when the content from that repo can't be properly validated externally.

[cafkafk]

I think this sadly is a consequence of those distributions very conservative release schedule, but ofc I'm not blocking anyone from potential solutions to this, I just don't think many current devs are excited for a major toolchain downgrade, so that route probably isn't optimal. We did at some point support a older toolchain, specifically so these distros would have some version of eza supported, but being on at least 1.70 now does seem reasonable to me, and the refactor wouldn't be minor if we were to downgrade.

[dsommers]

Yeah, I fully understand the resistance; being involved both as a developer and package maintainer for over a decade for multiple distributions and releases. The developer in me always wants the latest tool chains and latest features, the package maintainer in me screams in agony thinking of that. It's hard to find the right balance, a balance crucial to consider well if you want broader support across distributions.

Unfortunately, eza isn't a tool you can flatpak/snap; that would be a way too heavy framework to depend on. At the same time, eza/exa is just so much more convenient tool than good old ls. It would be pity to exclude distributions with a long term stable support schedule; after all - they provide far more stable environments than the more bleeding edge distros with the latest and greatest tool chains do.

I don't know the cargo build system well enough to know the possibilities ... but could it be possible to have optional dependencies? That way some of functionality which is impossible or just too invasive to get working could be disabled for those having an older tool chain available?

[ChrisDenton]

IIRC a number of distro are now shipping rustup so that a more recent compiler can be used.

[MartinFillon]

IIRC a number of distro are now shipping rustup so that a more recent compiler can be used.

you can also download it with curl (at least on ubuntu)