> macOS 12.3 removes /usr/bin/python This package encapsulates everything in a virtualenv, so that wasn’t the issue. In case anyone runs into something similar, my logs say this the removal of /usr/local/lib/.Python is the issue:
> dyld[545]: Library not loaded: @executable_path/../.Python > Referenced from: > /private/var/calendarserver/Library/CalendarServer/virtualenv > /bin/python > Reason: tried: > '/private/var/calendarserver/Library/CalendarServer/virtualenv/bin/../.Python' > (no such file), '/usr/local/lib/.Python' (no such file), '/usr/lib/.Python' > (no such file) Thanks for the conflicts_build advice—I’ll add it. > On Mar 17, 2022, at 15:41, Ryan Schmidt <ryandes...@macports.org> wrote: > > On Mar 17, 2022, at 14:37, Steven Smith wrote: > >> Thanks everyone for your responses and suggestions. >> >> Short story: I used the existing `sudo port install >> calendar-contacts-server` and … it works! >> >> Even though this project is old and archived, I’m not aware of any open >> source that replaces its functionality, and it’s now fully reliant on a >> MacPorts stack, so I expect it will work indefinitely now. >> >> The long story and the reason for my initial query: I had originally >> implemented a working instance without MacPorts, then wrote the Portfile to >> get a MacPorts version, then adopted the “if it’s not broke don’t fix it” >> attitude with my original, non-MacPorts Calendar server. So I kept that >> running until this week when there was some breaking change in the macOS >> 12.3 Python environment. > > macOS 12.3 removes /usr/bin/python. > > https://lists.macports.org/pipermail/macports-dev/2022-February/044121.html > > >> I tried a quick manual install and ran into this issue, and believe I got >> tangled up in stuff I had to fix a couple years ago to get the MacPorts >> version working. IIRC the solution involves setting the correct environment >> variables, as done in the Portfile. >> >> There’s one little issue I ran into, and I’d appreciate a suggested fix. The >> pip installer wants to see sqlparse==0.2.0 in the virtualenv, which it >> installs correctly, but for some reason breaks later when it finds a >> MacPorts-installed version of py27-sqlparse. The solution is to just >> uninstall this port. How should this conflict best be expressed in the >> Portfile? > > If this failure occurs at build time, use "PortGroup conflicts_build 1.0" and > "conflicts_build py27-sqlparse". > >
