exa: remove as unmaintained upstream

[oxalica]

Description of changes

ogham/exa#1243

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[teto]

Looks reasonable.

[peterhoeg]

Could we put in a compatibility symlink exa -> eza so that things don't break if people swap the packages?

[peterhoeg]

I mean a symlink to the binary.

[teto]

I find it more confusing than anything else, this should be up to users (else upstream would have relinquished the name)

[peterhoeg]

Exa upstream has allegedly gone AWOL. You could then argue that eza upstream should have a flag for putting in a compatibility symlink, but in order to follow the principle of least surprise, we could then handle it downstream.

[cafkafk]

You could then argue that eza upstream should have a flag for putting in a compatibility symlink

Hi, I'm eza upstream. I'm not sure how such a flag would work, but feel free to create a feature request outlining this, or perhaps a PR.

[oxalica]

I agree with @teto that it's confusing to alias one project to a fork maintained by a different group of people, even though the original author endorsed it. End-users should acknowledge this and then decide which one to use, or probably go back to coreutils.

[cafkafk]

maintained by a different group of people.

For the record, Mélanie Chauvel maintained exa for years and has been active in exa since 2018, and she is also a maintainer on eza.

I was made aware that Archlinux Extra does have symlink from exa to eza. There is also a noticeable amount of users that have asked for this.

That said, I personally prefer users making this a conscious choice.

But we might provide some feature flag that creates a symlink or something like it, and I'll make sure to add it to eza in nixpkgs on the following release as a lib.optional, in the same way we currently do gitSupport. That should make most people happy. (@peterhoeg)?

[oxalica]

maintained by a different group of people.

For the record, Mélanie Chauvel maintained exa for years and has been active in exa since 2018, and she is also a maintainer on eza.

Okay, that's reasonable.

But we might provide some feature flag that creates a symlink or something like it, and I'll make sure to add it to eza in nixpkgs on the following release as a lib.optional

We can definitely do that, probably just in installPhase. An override-able parameter exaAlias could be fine, as we already have {vi,vim}Alias for neovim here. Since exa is already removed, having a true default seems fine to me.

[dotlambda]

Why not

Suggested change

	exa = throw "'exa' has been removed because it is unmaintained upstream. Consider using 'eza', a maintained fork"; # Added 2023-09-07
	exa = eza; # Added 2023-09-07

?

[wegank]

For me, this was not acceptable before #254600. Now it is.

[dotlambda]

else upstream would have relinquished the name

They didn't say they wouldn't because they didn't say anything.

eza is clearly a continuation of exa so the latter should be an alias.

[cafkafk]

I would like if you could at least keep a trace telling users that they're not installing exa

[teto]

An override-able parameter exaAlias could be fine, as we already have {vi,vim}Alias for neovim here

and I find that weird too xD neovim is neither vim or vi so it's odd/confusing to create those aliases, especially as nix provides so many workarounds. Now that they are there I wont touch those but I feel we could have avoided that for eza/exa. Now I hope no one creates a new software called "exa" :s

Anyway I dont feel strongly about this but just to show creating the aliases is not obvious for everyone.