Requirement for PyGObject <3.47 causes conflicts on Ubuntu 24.04

[SimonAkers]

Commit 27dcc9c pinned the PyGObject library to version <3.47 to maintain compatibility with Ubuntu 20.04.

The default version of the gir1.2-gtk-3.0 package on 24.04, which to my knowledge is a dependency of the app, installs a version of PyGObject >3.47.

Pip will try to remove the existing newer package when installing the older one. However, since the package wasn't installed using pip, it cannot be uninstalled using pip.

I am not sure of a solution that would work for every case, but one possible solution for users may be to install an older version of the gir1.2-gtk-3.0 package if possible. I am yet to test this workaround.

In my situation this issue occurred in a docker container with a 24.04 base image. For my use case, it was sufficient to just change the base image to 22.04 and tweak a couple things (SimonAkers/docker-tdm@03c4bfa). I wanted to document this as an issue in case it shows up for someone else.

[guihkx]

This problem can be entirely avoided by using a virtual environment to install the dependencies, so they don't conflict with system packages. You were installing the dependencies with --break-system-packages, which is usually a really bad idea.

Besides, unless you have some specific reason to require the latest version of Ubuntu, I'd recommend staying on the oldest LTS version anyway.

[SimonAkers]

@guihkx thanks for the reply, here is my thought process.

This problem can be entirely avoided by using a virtual environment to install the dependencies, so they don't conflict with system packages.

To build some of the dependencies you need access to libraries which cannot easily be installed inside a venv (to my knowledge) such as for cairo. There exists vext, but I do not believe it supports all required packages. I may be wrong though, or there may be another solution.

I would appreciate any advice on how to run TDM strictly inside a venv if possible, as I'm aware that's an ideal solution.

You were installing the dependencies with --break-system-packages, which is usually a really bad idea.

For my use case in a rough docker container, it's acceptable usage. If it were on my host machine, then I agree it would not be very safe. However, if I can get everything inside a venv, I would not need to worry about it. Any advice?

[guihkx]

I think you're mixing things up.

PyGObject only depends on pycairo, and so to build it, you only need the headers package (libcairo2-dev, which you do), and a compiler toolkit (usually just installing the build-essential package group is enough).

When those two main things are ready, running pip install will build and install those dependencies from source automatically for you.

I would appreciate any advice on how to run TDM strictly inside a venv if possible, as I'm aware that's an ideal solution.

I'm honestly not too experienced with Docker, but you can probably come up with something adapted from this article I found.

[DevilXD]

@SimonAkers Docker usage is against the Project Goals, and is thus unsupported. If you run into issues, you're on your own.

Project Goals can be found here: https://github.com/DevilXD/TwitchDropsMiner?tab=readme-ov-file#project-goals

@guihkx While I really appreciate you helping other people with their Linux-related issues, please remember that most of the existence of this project depends solely on my availability, and I'm already struggling with keeping up to Twitch changing things around (see #462). TDM was never meant to be deployed anywhere, and making that easier leads us closer to people deploying farms with thousands of instances, and then Twitch putting in efforts to stop that and prevent TDM from working. This has already happened multiple times in the past (read more under the project goals), and while we can't prevent it entirely, we can at least try to discourage doing so.

[SimonAkers]

@DevilXD Appreciate your work, and I understand your reasons for not supporting docker.

My motivations for opening this issue were not to promote docker usage, but to make this potential issue known. It's not necessarily limited to docker, this issue can happen in standard Ubuntu 24.04 desktop. So I wanted to put any potential solutions out there in case a typical user has the problem.

I agree with closing the issue though, it's not something you technically are responsible for anyways. Again, thanks for your hard work!

[DevilXD]

I see. Thank you for understanding =)