Official Docker Image

[LucaDev]

I'd love to see an official docker image. This could be used in automated build pipelines (e.g. using gitlab) and prevent users from permanently installing the bad quality gstreamer plugins on their computer without thinking about the implications.

[AlexTMjugador]

PackSquash is really just an executable file, so you can use it in just about any platform or automated build pipeline by just invoking it as a command, after installing the appropriate GStreamer dependencies. You can download it automatically via GitHub Releases. It's not a complicated LAMP stack, Minecraft server, or any other software suite whose deployment, in my opinion, benefits much from being containerized.

However, I'm not precisely a Docker expert or enthusiast, so can you elaborate on the benefits and use cases you think such an image provides? Maybe it's a good idea after all and I do it myself, or even accept PRs for it.

---

On the other hand, about the possible "bad" GStreamer plugins concerns: although "bad" definitely sounds, well, bad, these plugins will not necessarily break your computer, crash frequently, or introduce any instability, so you shouldn't worry about that. Citing an official source:

gst-plugins-bad: a set of plug-ins that aren't up to par compared to the rest. They might be close to being good quality, but they're missing something - be it a good code review, some documentation, a set of tests, a real live maintainer, or some actual wide use. If the blanks are filled in they might be upgraded to become part of either gst-plugins-good or gst-plugins-ugly, depending on the other factors.

So this means that "bad" GStreamer plugins are so because the GStreamer team doesn't guarantee their high quality, which does not imply that they are of bad quality. And even if a plugin is considered high quality by the GStreamer team, that doesn't mean it's flawless.

Currently, PackSquash only pulls the GStreamer bad plugins distribution because of its hard soundtouch plugin dependency when processing audio files, which is used to implement pitch shifting. However, this plugin has portability problems, as it doesn't compile with a MSVC toolchain, and is not included in the macOS Homebrew package of bad GStreamer plugins. In v0.3.0, PackSquash will only try to use soundtouch when actually performing pitch shifting, which alleviates these concerns, and gives you the choice of not installing the set of bad plugins if you do not use the pitch shifting feature. You do not need any plugins to compile PackSquash, either.

[LucaDev]

The main advantage of a dockerized PackSquash is (at least in my opinion) the ability to easily use it in an automated build pipeline (e.g. Gitlab CI). If I find a few spare minutes I'll take a look at it and create a PR.

About gstreamer-bad: you're absolutly right. I should have read into it before blindly judging by it's name. There's still a slight advantage in using Docker. By pinning to specific - testeted - versions of libraries, we can assure that they are behaving the way we want them to. (Which is quite a week argument right now, because PackSquash doesn't depend heavily on 3rd party libraries)

[AlexTMjugador]

There's still a slight advantage in using Docker. By pinning to specific - testeted - versions of libraries, we can assure that they are behaving the way we want them to. (Which is quite a week argument right now, because PackSquash doesn't depend heavily on 3rd party libraries)

Even though as you said this doesn't matter much right now, pinning down the versions of dependencies can only make the end user experience more consistent, so I think that alone may be a good reason for using Docker. So yeah, go for it! 😄

[AlexTMjugador]

Hey @LucaDev! I've noticed you've created a fork, presumably to look into this issue, so I've decided to fix CI builds not working to give you a master branch you can use to cleanly make any changes you need. I hope this makes things easier :smile:

[realkarmakun]

Github Action looks cool but not everyone uses Github in their workflow. Painless official Docker image hosted on ghcr.io that exposes ready to go binary would be nice. Though it would have to be ubuntu image which takes a lot of space. I tried running packsquash on alpine image but it wasn't very successful even with all libs installed (glib, gstreamer and etc. ldd shoed some symbols still missing). @AlexTMjugador have you considered building static binary with musl? It would work with Alpine out the box Here is the link: https://github.com/emk/rust-musl-builder

[AlexTMjugador]

@realkarmakun PackSquash can't be statically linked to musl due to its dependency on GStreamer, whose plugins are dynamically loaded at runtime and whose readily available cross-compilation pkgconfigs target glibc. musl doesn't support dynamic loading when statically linking to it, and while it could be technically possible to dynamically link to musl instead of glibc, I could not get it to work well on Alpine Linux after countless attempts: https://github.com/ComunidadAylas/PackSquash-action/issues/8#issuecomment-997453488

Unless someone smarter than me figures out a way to make dynamically linked musl to work, I don't think that we can use a musl-based distro as a base for the Docker image. The rust-musl-builder repository you linked to doesn't seem to help with this headache, or for that matter any complex C library that's not mentioned there.

Another alternative would be switching to another container-friendly distro that uses glibc instead of musl, but I'm not aware of any. I've also considered refactoring PackSquash to drop the GStreamer dependency, but that will take a while at best, and I don't know if it is feasible to combine smaller off-the-shelf libraries to offer all the desired functionality.

In any case, I'm aware that a Docker container for PackSquash would be useful. As stated on the "Generalize and publish the internal Docker container" issue on the PackSquash GitHub action repository that links to this issue, the GitHub action would benefit from it too, although it internally builds a Docker container already. I welcome contributions in that regard 😄

[AlexTMjugador]

PR #111 would close this issue! :tada:

[AlexTMjugador]

111 was merged, so I'm closing this. The next release will document how to use the Docker image. Those interested in trying out the image already can do so from the GitHub repository container registry.