Как установить PyMOL 3.1 на Mac с Apple Silicon: руководство для научных исследований 2026

Руководство помогает исследователям выбрать между официальным DMG-пакетом, открытой сборкой через Homebrew и conda-окружением для PyMOL 3.1 на Mac с Apple Silicon. В статье разобраны архитектура arm64 и x86_64, удалённый доступ без собственного Mac, проверка скриптов, плагинов и изображений для публикации.

Установка PyMOL 3.1 на Mac с Apple Silicon должна начинаться с выбора архитектуры и сценария, а не со случайного запуска первого найденного установщика: для минимального обслуживания подходит официальный DMG, для нативной arm64-среды — Homebrew, а для проекта, связанного с conda, требуется отдельное совместимое окружение. Если в лаборатории нет Mac, сначала следует проверить реальный PDB или mmCIF-файл и научный скрипт на удалённом Apple Silicon Mac, а уже затем решать, какую конфигурацию сохранять.

Эта статья предназначена для трёх групп:

  • аспирантов и студентов, которым нужно подготовить изображения структуры для публикации, но в лаборатории есть только Windows или Linux;
  • исследователей, переносящих PyMOL-скрипты, плагины или Python-зависимости на Mac с Apple Silicon;
  • сотрудников университетской ИТ-службы, отвечающих за воспроизводимую macOS-среду для лаборатории.

00Сначала выберите сценарий установки PyMOL 3.1

PyMOL может использоваться на Mac с Apple Silicon, однако «запускается» не означает «работает в той же архитектуре». Официальный пакет, открытая сборка Homebrew и conda-окружение могут иметь разные требования к Python, Qt, плагинам и бинарным библиотекам. Поэтому перед загрузкой нужно определить, какой риск для проекта недопустим: отсутствие официальной поддержки, несовместимый плагин, сложная установка или отличие результата визуализации.

Сценарий Когда выбирать Что проверить до начала Когда остановиться
Официальный DMG Нужны готовый GUI, документация и официальный канал поддержки Лицензию, версию macOS, архитектуру пакета и требования поддержки Если лицензия не покрывает научную или публикационную работу
Homebrew и открытая сборка Нужна нативная arm64-среда и контроль командной установки Архитектуру Homebrew, формулу и зависимости из актуального репозитория Если критичный плагин существует только для коммерческого bundle
Отдельное conda-окружение Проект уже зависит от Python, Qt или пакетов conda Доступность пакетов для macOS arm64 и совместимость каналов Если нужная связка публикуется только для x86_64
Удалённый Mac В лаборатории нет физического Mac или требуется временная проверка VNC, SSH, передачу файлов, восстановление сессии и правила хранения данных Если конфиденциальные структуры нельзя передавать на внешний хост

Перед выбором стоит письменно зафиксировать четыре условия: нужна ли официальная поддержка, используются ли конкретные плагины, должен ли PyMOL вызываться из Python и будет ли изображение частью опубликованного результата. Официальная страница загрузки PyMOL и описание поддержки PyMOL должны проверяться непосредственно перед установкой, поскольку версии macOS, пакеты и условия поддержки меняются.

01Для официального рабочего места используйте DMG и проверьте лицензию

Официальный DMG — наиболее рациональная точка старта для исследователя, которому нужен графический интерфейс без самостоятельной сборки зависимостей. Это не означает, что он автоматически решит проблему любого плагина: внешние модули могут иметь собственные ограничения по архитектуре и версии Python.

Минимальная последовательность выглядит так:

  1. Откройте официальный раздел загрузки PyMOL и сопоставьте доступный пакет с используемой версией macOS и моделью Mac.
  2. Скачайте DMG из официального источника, откройте его средствами Finder и переместите приложение в каталог программ.
  3. Запустите PyMOL один раз без исследовательского проекта, чтобы отделить проблему установки от ошибки файла, плагина или пользовательской конфигурации.
  4. Поместите файл лицензии в место, указанное официальной документацией, и проверьте, что приложение видит именно эту лицензию.
  5. Создайте отдельную тестовую папку с обезличенной структурой, скриптом и каталогом для изображений.

Не следует считать образовательную лицензию универсальным разрешением на любую научную деятельность. Если результат используется в исследовательском проекте, диссертации или публикации, условия нужно сверить с официальными разъяснениями по образовательной лицензии. Бесплатный доступ для обучения и право применять программное обеспечение в формальной исследовательской работе — не одно и то же.

Rosetta 2 также нельзя включать «на всякий случай» во всей системе. Сначала нужно выяснить архитектуру приложения:

uname -m
file "/Applications/PyMOL.app/Contents/MacOS/"*

arm64 указывает на нативный путь Apple Silicon, а x86_64 — на Intel-архитектуру, для которой может потребоваться слой перевода. Описание среды трансляции Rosetta 2 от Apple следует использовать для проверки конкретного случая, а не как доказательство полной совместимости всех плагинов.

Базовая приёмка официального варианта должна включать:

  • открытие представительного PDB или mmCIF-файла;
  • выполнение небольшой команды загрузки и выбора цепи;
  • смену представления секторов, поверхности или лент;
  • применение шрифта, цвета и ориентации камеры;
  • экспорт изображения в формате, который реально использует автор статьи.

Если структура открывается, но шрифт, подписи, плагин или экспорт отличаются от лабораторного результата, установка ещё не прошла приёмку.

02Для нативной arm64-среды отделите Homebrew от официального пакета

Homebrew подходит, когда исследователь сознательно выбирает самостоятельное обслуживание и хочет удерживать рабочую среду ближе к arm64. Это особенно полезно для командных сценариев, автоматизации и проектов, где графический интерфейс является только частью обработки. При этом открытая сборка не должна автоматически восприниматься как функциональный эквивалент коммерческого пакета: различия могут затрагивать поддержку, документацию, плагины и интеграционные инструменты.

Сначала проверьте архитектуру текущего терминала и префикс Homebrew:

uname -m
brew --prefix
brew config

Документация Homebrew по архитектуре и префиксам установки помогает понять, не запускается ли терминал под Rosetta и не используются ли формулы из чужой архитектуры. После этого проверьте актуальное состояние формулы или биоинформатического репозитория в Homebrew Bioinformatics, а сведения о самой открытой реализации — в репозитории PyMOL Open Source.

Практический порядок такой:

  1. Откройте новый терминал в требуемой архитектуре и убедитесь, что uname -m возвращает ожидаемое значение.
  2. Проверьте источник формулы и доступность пакета до изменения существующей лабораторной среды.
  3. Создайте отдельный каталог проекта и не смешивайте его с Python-окружением, которое используется для других инструментов.
  4. Установите пакет средствами Homebrew, сохранив вывод команды и список зависимостей.
  5. Запустите PyMOL из того же терминала и зафиксируйте путь к исполняемому файлу.
  6. Повторите загрузку структуры, выполнение скрипта и экспорт изображения.

Проверка бинарного файла важнее, чем одно успешное открытие окна:

file "$(which pymol)"
python3 -c "import platform; print(platform.machine())"

Значения должны соответствовать выбранной схеме. Если оболочка arm64 вызывает x86_64-Python, а PyMOL загружает модули из другого префикса, проект получает скрытую зависимость от Rosetta. Такая конфигурация может работать на одном Mac и перестать запускаться после обновления формулы или Python.

03Для conda создайте отдельную среду и не смешивайте архитектуры

Conda удобна для исследовательских проектов, где PyMOL вызывается вместе с Python, Qt, обработчиками структурных данных или другими пакетами. Но именно здесь чаще всего возникает ошибка «установка завершилась, а импорт не работает»: менеджер окружений пытается согласовать пакеты, опубликованные для разных платформ или каналов.

Официальная документация PyMOL по conda должна быть главным источником для проверки текущего состояния пакетов на macOS ARM. Важно повторно проверить её перед развёртыванием, потому что доступность сборки для arm64, название канала и требования к окружению могут измениться.

Создайте новое окружение, не разрушая существующее:

conda create -n pymol31-arm python
conda activate pymol31-arm
python -c "import platform; print(platform.machine())"
conda info

Название окружения здесь служит только меткой; оно не доказывает архитектуру. Фактические сведения нужно получить из platform.machine(), вывода conda и списка установленных пакетов.

При диагностике проверяются четыре уровня:

  • архитектура самого conda-интерпретатора;
  • наличие PyMOL для данной платформы;
  • совместимость Qt с графическим запуском;
  • происхождение Python-модуля и плагинов.

Если проект требует строго чистой arm64-среды, а официальный bundle или нужная conda-связка рассчитаны на x86_64, не следует принудительно смешивать пакеты. Рабочие варианты — перейти к открытой arm64-сборке или разделить среду: один изолированный контур оставить для совместимости, а нативный контур использовать для новых скриптов.

Минимальная проверка conda-сценария:

python -c "import sys, platform; print(sys.executable); print(platform.machine())"
pymol -cq test_structure.pml

Файл test_structure.pml должен загружать обезличенную структуру, применять несколько команд выбора и сохранять результат. Если графическое окно не требуется, безоконный запуск позволяет отдельно проверить скриптовую часть. Однако это не заменяет тестирование шрифтов, камеры, рендеринга и изображения, если конечная цель — рисунок для статьи.

04Для удалённой работы разделите вычисления и передачу изображения

Когда в лаборатории нет Mac, удалённая аренда Apple Silicon Mac может закрыть именно задачу проверки macOS-среды, но её нельзя оценивать по ощущению от обычного локального компьютера. PyMOL выполняет загрузку, обработку и рендеринг на удалённом хосте, тогда как VNC передаёт операционной системе исследователя последовательность изображения и действий. Поэтому задержка интерфейса и время вычисления структуры — разные показатели.

Для первичной проверки потребуется:

  1. Подготовить обезличенный PDB или mmCIF-файл, тестовый .pml-скрипт и небольшой набор плагинов.
  2. Загрузить файлы на удалённый Mac через согласованный канал, не копируя туда исходные данные с ограниченным доступом.
  3. Подключиться по VNC и проверить вращение, масштабирование, выбор объектов, смену представлений и работу меню.
  4. Открыть SSH-сеанс и выполнить тот же скрипт без графического интерфейса.
  5. Скачать итоговое изображение и журнал команд обратно в локальное хранилище.
  6. Разорвать сеанс, подключиться снова и проверить, сохраняются ли файлы, окружение и состояние проекта.
  7. Сравнить изображение с эталоном, созданным в текущей лабораторной среде.

Для работы с удалённым Mac полезно заранее изучить условия NUKCLOUD, а вопросы по подключению и передаче файлов сверить с разделом помощи NUKCLOUD. Конкретные показатели задержки, длительность рендеринга и стабильность непрерывной сессии нельзя переносить с одного узла на другой без реального теста. Если такие данные не подтверждены записью испытаний, их следует оставить без числовой оценки.

Контрольный сценарий должен имитировать публикационную задачу, а не демонстрацию запуска:

  • загрузить фактическую тестовую структуру;
  • выполнить лабораторный скрипт;
  • получить нужную ориентацию и цветовую схему;
  • проверить подписи, шрифты и разрешение;
  • экспортировать изображение;
  • повторить процедуру после восстановления удалённой сессии.

05Для переноса проекта принимайте результат по структуре, скрипту и изображению

Сохранённый файл сессии PyMOL сам по себе не доказывает воспроизводимость. В нём могут быть ссылки на локальные файлы, скрытые настройки, отсутствующие плагины или состояние, которое невозможно восстановить на другом Mac. Для передачи проекта лучше хранить входные данные, команды, версии и результат как отдельный набор.

Перед миграцией отметьте:

  • точное имя и контрольную сумму входного PDB или mmCIF-файла;
  • командный файл PyMOL и вызываемые им внешние скрипты;
  • перечень плагинов и способ их установки;
  • архитектуру Python и PyMOL;
  • настройки шрифта, камеры, цветов и формата изображения;
  • журнал ошибок и предупреждений;
  • эталонный экспорт для визуального сравнения.

Проверка плагина должна включать не только факт появления пункта меню. Нужно выполнить ту операцию, ради которой плагин установлен, открыть полученный объект и сохранить его в формате, который нужен проекту. Если плагин импортирует Python-библиотеку, отдельно зафиксируйте путь импорта и архитектуру этой библиотеки.

Чек-лист приёмки

  • [ ] Архитектура Mac, терминала, Python и PyMOL записана отдельно, без предположений по названию окружения.
  • [ ] Выбран только один основной путь: DMG, Homebrew или изолированная conda-среда.
  • [ ] Условия лицензии проверены для обучения, исследования и публикации.
  • [ ] Представительный PDB или mmCIF-файл открывается без ручного исправления.
  • [ ] Скрипт выполняется в графическом и, если требуется, безоконном режиме.
  • [ ] Все критичные плагины выполняют реальную операцию, а не только устанавливаются.
  • [ ] Цвета, выборки, представления, шрифты и камера совпадают с эталоном.
  • [ ] Изображение экспортируется в рабочем формате и открывается после скачивания.
  • [ ] Удалённая сессия восстанавливается, а временные файлы не нарушают правила хранения данных.
  • [ ] Для проекта сохранены команды, версии, источники пакетов и инструкция повторного запуска.

Если не проходит архитектурная проверка, следует вернуться к выбору маршрута, а не добавлять случайные ключи запуска. Если не совпадает изображение, сначала сравниваются входной файл, скрипт, шрифты и плагины. Если не проходит только удалённое взаимодействие, локальная установка может быть корректной, но удалённый вариант не подходит для интерактивной подготовки рисунков.

После такой проверки решение можно сформулировать без догадок:

  • оставить DMG, если проекту важнее официальный канал и предсказуемый GUI;
  • оставить Homebrew, если подтверждены нативная arm64-архитектура и все нужные операции;
  • сохранить conda отдельно, если проект действительно зависит от Python-пакетов;
  • использовать две среды, если совместимость старого плагина и нативная разработка имеют разные требования;
  • отказаться от маршрута, если он не воспроизводит реальный рисунок или нарушает лицензионные условия.

06Часто задаваемые вопросы

Rosetta 2 и Mac с M‑чипом

Rosetta 2 нужна не каждому варианту PyMOL. Она появляется в цепочке, когда приложение или зависимость собраны для Intel. Нативный arm64-путь предпочтительнее для нового проекта, но старый плагин может потребовать отдельного x86_64-окружения. Без проверки file, platform.machine() и фактического запуска нельзя делать вывод только по модели Mac.

DMG или Homebrew

DMG выбирают для готового рабочего места с официальной лицензией и минимальным числом решений при установке. Homebrew выбирают для контроля зависимостей, командной работы и нативной архитектуры. Установка обоих вариантов в один общий путь создаёт риск, что команда запускает не тот бинарный файл, который исследователь только что проверил.

Почему conda завершается ошибкой

Conda может не найти согласованный набор пакетов для macOS arm64, либо выбрать библиотеку, предназначенную для x86_64. Дополнительную путаницу создают уже активированная среда, несколько каналов и Qt, установленный из другого источника. Чистая среда, вывод архитектуры и фиксация канала позволяют определить причину раньше, чем начнётся ручное копирование библиотек.

Удалённая работа из лаборатории

Удалённый Mac полезен как испытательный контур: исследователь получает реальную macOS-среду и может проверить GUI, SSH, сценарии и экспорт. Но конфиденциальные структуры нельзя передавать без разрешения владельца данных. До оплаты длительного периода разумно пройти короткую проверку на обезличенном файле и убедиться, что полученное изображение можно забрать без потери качества.

Совпадение скриптов и плагинов

Сравнивать нужно не только финальное окно, но и входной файл, выборки, представления, цветовую схему, подписи и экспорт. Для каждого плагина фиксируется версия и выполняется конкретная операция. Если результат отличается, старую и новую среды временно сохраняют параллельно; удалять рабочий вариант до объяснения расхождения рискованно.

Для структурной визуализации решающим является не сам факт наличия PyMOL на Mac, а доказанная цепочка «файл — окружение — скрипт — плагин — изображение». Если лабораторные Windows или Linux-компьютеры не дают доступа к macOS, текущий вариант обычно ограничен отсутствием нужной платформы, невозможностью проверить Mac-специфичный GUI и дополнительными затратами на покупку отдельного устройства. В такой ситуации аренда удалённого Mac через NUKCLOUD позволяет сохранить проверенный маршрут на срок проекта, не обещая заранее совместимость каждого плагина; подходящую среду и условия доступа можно сопоставить на странице доступных вариантов NUKCLOUD.