Arch Linux User Repository

@alerque

in the process of setting up official packaging for this

Awesome :)

1. We chose lux-cli as a package name because we wanted to avoid conflicts. There's also a lux package in nixpkgs, so we call ours lux-cli there too. Then, there's lux-lua (which is packaged separately in nixpkgs). "lx" as a choice for the binary name is due to it being the symbol for the unit lux (illuminance) in the SI units system. It's probably less likely to clash with "lux".
2. I don't use Arch Linux but took over maintainership of lux-cli in AUR. So I don't know if the remap is necessary. Probably not, since we don't use it anywhere else. I suppose it was added for nicer debug output?
3. lux-cli-bin installs a bundle the includes a lux-lua lux.so for all supported Lua versions. There are mechanisms implemented that enable Lux to detect the appropriate one and add it to the package.cpath when running commands like lx path or lx run. If packaging them separately, I would suggest to install them to the standard Lua paths. Btw, we use cargo_packager in an xtask to build the lux-cli-bin package: https://github.com/lumen-oss/lux/blob/d12f9686024b54d988e36ad6da8c57b61dab8e20/xtask/src/main.rs#L284

I'm in the process of setting up official packaging for this, but it's a bit of a mess! Questions:

1. Why is this called "lux" as a project, "lux-cli" as an AUR package name and "lx" as a binary? I understand the AUR namespace was taken, but migrating to official repos I'd actually be able to override that. The lux shell script has a tiny amount of GH stars and has been years since it got new AUR traction. Should I name the package that contains the CLI just lux (this feels most correct to me)? Or lx? Or lux-cli to match crates.io? The "provides" and "conflicts" in this package are clearly all wrong in any case.

2. Is the --remap-path-prefix dance really necessary? That feels like something is wrong in the upstream build tooling instead of something that should need to be done while building packaging.

3. Should I be breaking out the SO modules into lua51-lux, ..., lua54-lux, lua-lux and so forth for packages that provide the Lua module? The current approach of the -bin package in the AUR seems wrong, but I'm not sure what the right thing to do is as those are also not installed in standard Lua paths. Should they be?

lux-cli-bin comes bundled with lux-lua.

diff --git a/PKGBUILD b/PKGBUILD
index 9f8b106..27c05d4 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,7 +1,7 @@
 # Maintainer: Firegem <firinggems@hotmail.com>
 # shellcheck disable=SC2034,2154,2164
 pkgname=lux-cli
-pkgver=0.7.4
+pkgver=0.8.3
 pkgrel=1
 pkgdesc="A luxurious package manager for Lua"
 arch=('x86_64')
@@ -13,7 +13,7 @@ provides=('lx')
 conflicts=('lux-cli-git')
 options=('!lto')
 source=("${pkgname}-${pkgver}.tar.gz::${url}/archive/refs/tags/v${pkgver}.tar.gz")
-sha256sums=('ee62248c4eeef8bfa674f78009fbb9b43b04e1120b3be1ba2095984597fb754e')
+sha256sums=('b053222ca0d8614167b7528716e2a5fdb24bff937cc0ce1d413ea579d62550b7')

 prepare() {
     cd "${pkgname%-cli}-${pkgver}"

Can you add me to maintainer?

0.8.3 is coming!

This package doesn't contain lux-lua, so you'll need to build that yourself as there's currently no aur package for it.