Contributing to Picard 3.0

shiny.song8299 · August 9, 2024, 6:07pm

I see that work is continuing on Picard 3.0 with progress on Apple Silicon support. I have an Apple Silicon device and Python experience. I’d be happy to assist if you need beta testers or some development assistance.

I dug into the issue trackers and found this pull request which says “We will get back to this, but likely only after we have moved to PySide6 and there is at least a 6.7.1 release available on pypi.” As of 18 June 2024, PyPI has PySide6 6.7.2. The PySide6 branch has been dormant for two months.

From this analysis, it seems productive for me to pull down the PySide6 branch and try to get it building on my Apple Silicon machine now that PySide6 v6.7.2 is available. Is that correct?

Sophist · August 9, 2024, 7:29pm

IMO this might better be flagged using a Picard ticket on the Metabrainz Jira tickets web site.

@outsidecontext ?

shiny.song8299 · August 9, 2024, 8:52pm

If appropriate, I’d be happy to submit a ticket over there. I pinged here because it looked like that ticketing system is primarily for bug reporting. Looks like it requires a third account? (Atlassian + metabrainz.org + GitHub)

rdswift · August 9, 2024, 9:54pm

I’m more of a “when I have some time” contributor, helping out when I can. The two people leading the work on Picard are @Zas and @outsidecontext, and I’m sure they will welcome any contributions you can provide (especially testing and work on the macOS stuff).

If you’re in Matrix, there’s a room specifically for Picard Development (#musicbrainz-picard-dev:chatbrainz.org). You’re more than welcome to join us there as well.

I look forward to working with you.

Bob Swift (aka rdswift)

outsidecontext · August 9, 2024, 10:17pm

Thanks for your interest in helping. Having someone with actual access to a Apple Silicon device would be great, as I’ve been flying blind so far.

The PySide6 experiment is dead for now, so. Encountered too many issues and instabilities, and config migration would have been a pain. So zas and I decided to abandon this approach and stay with PyQt, which is proven and stable. There had been two main reasons for considering PySide: 1. It’s released together with new Qt releases, so theoretically might be more up to date and 2. they did provide Apple Silicon binaries when PyQt did not yet.

But PyQt now provides Apple Silicon binaries, although with one downside that they only provide partially universal2 binaries. The PyQt6 packages on PyPI consist of two parts: The PyQt6 package, which contains the actual Python modules providing the Qt bindings, and the PyQt6-Qt6, which provides pre-compiled Qt6 binaries.

The PyQt6 package is available for macOS as a single universal2 binary. The PyQt6-Qt6 however has separate packages for arm64 and x86_64. AFAIK this is due to package size limits on PyPI.

I would have liked to provide a single universal package, but that is not a strict requirement. We could as well have two separate packages, one for arm64 and one for x86_64.

Currently there are multiple options to go about providing Apple Silicon support:

Adapt the build process to build two separate app packages for arm64 and x86_64.
Instead of using the Qt6 binaries from PyPI compile Qt6 ourselves. This probably also involves rebuilding PyQt6. I really wanted to avoid this overhead, though. Picard’s packaging is already complex enough.
Use the Qt6 binaries from the PyQt6-Qt6 package, but combine the individual binary files for arm64 and x86_64 into a combined universal2 binary. I haven’t investigated further how feasible this is, the Qt6 packages consist of quite a few individual binaries. But theoretically the structure should be the same in both architectures and some script could combine the two architectures for each file.

If you want to help digging into this and providing a solution you are more then welcome. I personally lack both the time and a machine to properly test on. My current focus will be getting a bugfix release for Picard 2.12 out and then focusing on the new plugin system again, so it would be quite a while until I will get back to macOS packaging.

As rdswift wrote best would be to get in touch in the chat.

If you want some pointers building the Picard app package on macOS is done with PyInstaller. The production is being build with the macos* scripts in picard/scripts/package at master · metabrainz/picard · GitHub . The build is controlled by Gitlab CI with picard/.github/workflows/package-macos.yml at master · metabrainz/picard · GitHub

But for local development and testing when running Picard from the source tree the simple answer is actually that one needs to install pyinstaller with pip and then build the app bundle with pyinstaller --clean picard.spec. That would build the app bundle for the system, architecture, though, no universal binaries.

I had the basic changes for building universal2 packages in the branch at Commits · phw/picard · GitHub . As far as I could tell it worked except for the Qt6 binaries, as discussed above.

shiny.song8299 · August 10, 2024, 1:29pm

Awesome - this is the context I needed. Thanks for taking the time to brain dump. I’ll start poking in the directions indicated and ping the matrix chat when/if I have something meaningful to share.

Also, thank you for your work on this in general. Picard is a core part of my music experience. I currently run it via this Docker image on Unraid because (1) that’s where my music collection lives and (2) Apple Silicon. Unfortunately the releases lag a bit and it’s a bit clumsy running desktop software via the browser. It would be lovely to get a clean Picard experience on my primary workstation, do the curation there, and shuffle stuff off to the NAS after it’s tidied up.

outsidecontext · August 10, 2024, 4:21pm

Much appreciated, let me know if I can assist you in some way setting things up.

On a side note I just merged changes related to localized sorting that avoid segfaults on macOS. It looks like these might have been related to various crashes on macOS in the past. I was now also able to upgrade the builds to the latest PyQt6 / Qt6 without issues. This resolves some of the headaches

Chop4868 · November 27, 2025, 4:43pm

Hi, I was able to buld an Apple Silicon native version on my Mac mini M4 running macOS 26.1 by doing the following:

made sure I had python 3.12:

brew list | grep python

installed qt:

brew install qt

verified qt:

brew --prefix qt

installed the make and pkg-config:

brew install cmake pkg-config

I keep all my build projects under one directory:

cd programming_projects

created a virtual environment:

python3.12 -m venv picard-venv

activated the venv (I use fish shell):

source picard-venv/bin/activate.fish

upgraded python tools:

pip install --upgrade pip setuptools wheel

installed the necessary things:

pip install PyQt6 PyQt6-Qt6

pip install mutagen

pip install requests

pip install packaging

pip install setuptools_scm

pip install pyinstaller

cloned the picard repository:

git clone 


cd picard

installed the requirements for macOS:

pip3 install -r requirements-macos-11.0.txt

installed the pythong qt6 things:

pip install PyQt6 PyQt6-Qt6

exported the qt path:

export QT_PATH=$(brew --prefix qt)

export PATH="$QT_PATH/bin:$PATH"

installed and linked libdiscid:

brew install libdiscid

ln -s /opt/homebrew/lib/libdiscid.0.dylib libdiscid.0.dylib

found that the homebrew version of fpcalc won’t work because the Picard seems to need a static version, so I cloned and built it:

https://github.com/acoustid/chromaprint

git clone https://github.com/acoustid/chromaprint.git

cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TOOLS=ON .

make

sudo make install

but running the script fails because it looks for fpcalc in the bundle, which it doesn’t put in the bundle, not sure why, so I modified the script to add fpcalc to the bundle:

(added right before the check for fpcalc)

# Copy fpcalc into the app bundle

mkdir -p "$APP_BUNDLE/Contents/Frameworks"

cp  /usr/local/bin/fpcalc "$APP_BUNDLE/Contents/Frameworks/fpcalc"

chmod +x "$APP_BUNDLE/Contents/Frameworks/fpcalc"

this successfully built the app bundle and it seems to work for the most part so far. Only issue I’ve run into in my quick testing is that the “Lookup in Browser” button doesn’t do anything.

I’m not really a programmer but have dabbled building things and have been trying to learn python. Not sure if this will help, but I do have a Mac mini M4 to test things with if that would be of any help to the project.

thanks!

Jim

Sophist · December 1, 2025, 10:37am

Jim

Thank you for posting this. I am not particularly conversant with the build process in general, and as I am not a Mac user I am even less knowledgeable (if that is possible) about the process for creating Mac builds.

I would hope that the volunteer team (and in particular whoever in the team has a Mac - if indeed there is someone) will take note and see if anything you have achieved can be usefully used to improve the automated build process.

However…

The build process is done using Github actions and runners, so the Picard volunteer team are limited by what is achievable with the runners Github provides. I know that another project I have had involvement with (meerk40t) had to build a specialised bespoke Guthub runner to achieve the Mac builds it wanted.
Mac builds can depend on the version of both hardware and operating system types it needs run on. Sometimes you need multiple versions. Sometimes you need to build a version in a very specific way so that it runs on multiple versions of hardware/os.
Testing these builds against the various combinations of hardware and O/S can be impossible - because there are many such combinations and no one has that hardware lying around to test and AFAIK there isn’t an automated service you can use.

But as I say, perhaps the Mac experts on the volunteer team can make use of this excellent write-up to improve the process.