Development of v0.4.9.4

[git-developer]

The build of v0.4.9.3 failed. This might be related to the python version: it fails on bullseye, focal, jammy (python <3.11) and works on bookworm, trixie, noble (python >= 3.11). If you'd like to debug locally, you can run:

$ docker build -o build-output --build-arg BASE_CODENAME=focal .

The first failing commit is b3edd80.

[C0rn3j]

focal doesn't have the build deps in the repo, jammy fails on the following error and noble just works with this.

Got it a bit further, but I don't have time at the moment to figure out why jammy refuses to use the wheel files atm.

Maybe we can get away by installing installer from pip if you want to try that.

docker build -o build-output --build-arg BASE_CODENAME=jammy .

ARG BASE_OS=ubuntu
ARG BASE_CODENAME=noble
FROM $BASE_OS:$BASE_CODENAME AS build-stage

# Download build dependencies
RUN <<EOR
  set -eu

  apt-get update
  apt-get install -y --no-install-recommends \
      gcc \
      librsvg2-bin \
      linux-headers-generic \
      python3-dev \
      python3-setuptools \
      python-is-python3 \
      python3-build \
      python3-venv \
      python3-poetry \
      python3-installer
  apt-get clean && rm -rf /var/lib/apt/lists/*
EOR
# Prepare working directory and target
COPY . /work
WORKDIR /work
ARG TARGET=/build/usr

# Build and install
RUN <<EOR
  set -eu
  #pip install poetry
  echo $(command -v python3)
  python -m build --wheel
  python -m installer --destdir="${TARGET}" dist/*.whl

  # Provide input-event-codes.h as fallback for runtime systems without linux headers
  cp -a \
      "$(find /usr -type f -name input-event-codes.h -print -quit)" \
      "$(find "${TARGET}" -type f -name uinput.py -printf '%h\n' -quit)"

  # Create short name symlinks for static libraries
  suffix=".cpython-*-$(uname -m)-linux-gnu.so"
  find "${TARGET}" -type f -path "*/site-packages/*${suffix}" \
    | while read -r path; do ln -sfr "${path}" "${path%${suffix}}.so"; done

  # Put AppStream metadata to required location according to https://wiki.debian.org/AppStream/Guidelines
  metainfo=/build/usr/share/metainfo
  mkdir -p "${metainfo}"
  cp -a scripts/sc-controller.appdata.xml "${metainfo}"

  # Convert icon to png format (required for icons in .desktop file)
  iconpath="${TARGET}/share/icons/hicolor/512x512/apps"
  mkdir -p "${iconpath}"
  rsvg-convert --background-color none -o "${iconpath}/sc-controller.png" images/sc-controller.svg
EOR

# Store build metadata
ARG TARGETOS TARGETARCH TARGETVARIANT
RUN export "TARGETMACHINE=$(uname -m)" && printenv | grep ^TARGET >>/build/.build-metadata.env

# Keep only files required for runtime
FROM scratch AS export-stage
COPY --from=build-stage /build /

2.887 removing build/bdist.linux-x86_64/wheel
2.943 * Creating virtualenv isolated environment...
2.943 * Installing packages in isolated environment... (setuptools>=60, wheel)
2.943 * Getting dependencies for wheel...
2.943 * Building wheel...
2.943 Successfully built sccontroller-0.4.9.3-cp310-cp310-linux_x86_64.whl
2.985 usage: python -m installer [-h] [--destdir path] [--compile-bytecode level]
2.985                            [--no-compile-bytecode]
2.985                            wheel
2.985 python -m installer: error: unrecognized arguments: dist/sccontroller-0.4.9.3-cp312-cp312-linux_x86_64.whl

[git-developer]

And once more concerning the scc script: AppImages actually require a single executable because that's what they run when called. So we can't avoid the facade.

[git-developer]

Do you know whether the shebang patching is OK or if there's a cleaner way, @C0rn3j?

[C0rn3j]

Does scc actually work for you outside of AppImages?

Because when I was testing it, it always failed to pass parameters, which was why I just fixed the binaries instead.

... enable jammy-proposed repo in apt sources ...

I will think about that. I agree that using the proposed repo is cleaner. Currently, the Dockerfile can be used for all distros. The proposed repo requires an explicit check for jammy, and the URL differs per arch 🙄

The idea would be that upstream fixes their package and we won't have to carry any workarounds

BTW, I skipped the poetry dependency, it's not used.

Pretty sure it failed on Jammy for me without it. I could be wrong about it being necessary, if you're sure, sure.

EDIT: ah, you removed the installer module.

Do you know whether the shebang patching is OK or if there's a cleaner way, @C0rn3j?

Wouldn't retaining installer module and specifying a prefix help here?
https://installer.pypa.io/en/stable/cli/installer/

Maybe we should switch to wheel instead?
https://packaging.python.org/en/latest/key_projects/#wheel

Actually looks like what you're doing is same/similar?
https://wheel.readthedocs.io/en/latest/user_guide.html#installing-wheels

Is there a reason to not source the activate file of venv and just running pip instead of .env/bin/pip install?

Maybe we should just upgrade pip from pip in and everything else in the venv/build env, and then upgrade setuptools and whatever else that's needed to latest to ensure our envs are less unique instead of having workarounds for each weird distro version.

[git-developer]

Does scc actually work for you outside of AppImages?

I never tried, I always use an AppImage to avoid the dependency hell. But there should be no difference if scc is called inside or outside an AppImage. In the end, it's just a zipped directory (you can unpack it using arg --appimage-extract) with a AppRun binary doing some lib-loading-foo and delegating to the main executable.

retaining installer module and specifying a prefix

I tried, it didn't help. As written above, local was suffixed always. Please try yourself, maybe I've overseen something. I never got in touch with installer, wheels and the like. I appreciate everything that slims down the process.

Is there a reason to not source the activate file

No, I just chose it because it's a single command. Would that improve / simplify something?

Maybe we should just upgrade pip ...

Sounds great! I'm happy that the build is working now, so we can use the CI to ensure any refactoring does not break anything. Can you prepare something in a separate branch? Once it's ready to try, we can simply run a manual GitHub Action build and use the artifacts for local tests.

[C0rn3j]

I never got in touch with installer, wheels and the like. I appreciate everything that slims down the process.

That makes two people learning as they go :D

there should be no difference if scc is called inside or outside an AppImage.

The problem is that migrating to pyproject.toml and the associated build process made the executables be a generated script pointing to a function, as opposed to the executables just being executed as is.

That's why I had to mark them as executable, edit some of them to have a main function and why I was able to throw out scc (or so I thought I could throw it).

No, I just chose it because it's a single command. Would that improve / simplify something?

One could accidentally run pip after it and install thing into the host by accident, but if it works as is, other than that, perhaps not?

Sounds great! I'm happy that the build is working now, so we can use the CI to ensure any refactoring does not break anything.

Agree. Let's push that in a separate PR. I'll get to it some time in the future™, hopefully by next week or something.

It's going to be nice as even Arch has setuptools out of date by a few months at the moment.

[git-developer]

I tested v0.4.9.4, both daemon and GUI work great. I created issues for a few error messages that I found in the log. They didn't impact the user experience / program behavior.