По официальным данным, Julia 1.13.0 выпущена 9 сентября 2026 года и указана как текущая стабильная версия на официальной странице загрузок Julia. Поэтому для нового проекта на Mac с Apple Silicon выбирайте официальный канал juliaup, а не случайный пакет из стороннего источника. Старый проект не обновляйте поверх исходной среды: сохраните прежнюю Julia и Manifest.toml, затем проведите отдельную проверку пакетов, результатов и графики в Julia 1.13.
Кому пригодится это руководство: исследователям, у которых рабочие машины работают под Windows или Linux, но проект нужно проверить в macOS arm64. Оно также рассчитано на аспирантов, переносящих старую задачу, и сотрудников университета, отвечающих за воспроизводимую среду и удалённый доступ к Mac.
Последнее обновление: 19 сентября 2026 года. Данные повторно сверены с официальными страницами загрузки Julia, руководством по установке и документацией Pkg.
Начните с фиксации исходного состояния
Проблема обычно начинается не с самой установки. Один участник проекта ставит Julia из DMG, другой использует пакетный менеджер, третий запускает старый Intel-бинарник через Rosetta. В результате команда julia открывается у всех, но каналы, пути к библиотекам и наборы зависимостей оказываются разными.
Перед изменениями сохраните:
Project.tomlиManifest.toml;- исходный код, конфигурацию и скрипты запуска;
- контрольную копию входных данных или их обезличенный образец;
- список используемых Julia-пакетов и внешних программ;
- вывод текущей версии Julia и сведения о платформе.
versioninfo()
using Pkg
Pkg.status()Сохраните вывод в текстовый файл. Это не доказывает совместимость с будущим окружением, но создаёт точку сравнения. Если проект находится в системе контроля версий, добавьте туда файлы окружения отдельно от результатов расчёта.
Как выбрать канал и способ установки
| Ситуация | Предпочтительный вариант | Почему | Условие остановки |
|---|---|---|---|
| Новый проект на Apple Silicon | Официальный juliaup и стабильный канал | Версию проще фиксировать и менять без ручной замены приложения | Канал не показывает ожидаемую версию или запускает другой путь |
| Старый проект с опубликованными результатами | Исходная Julia плюс изолированная Julia 1.13 | Можно сравнить зависимости и результаты без разрушения старой среды | Пакет или внешний бинарник работает только в старом окружении |
| Внутренняя политика запрещает установщики | Официальный ручной пакет с проверкой источника | Администратор сохраняет контроль над распространением | Нет подтверждения подписи, архитектуры или происхождения файла |
| Нужна разработка будущей функции | Канал предварительного просмотра отдельно от стабильного | Эксперимент не меняет рабочую среду | На этом канале начинают проверять опубликованные результаты |
juliaup; ручные сборки для macOS доступны на [официальной странице платформенных загрузок](https://julialang.org/downloads/platform/#macos). Скачивайте установщик только из официального источника, а не из произвольного архива.
Для нового канала проверьте:
juliaup status
julia --version
which juliaНазвание канала и доступные действия могут меняться вместе с juliaup, поэтому сверяйте поведение с официальным руководством по установке Julia. Важны три независимых признака: команда найдена, путь ожидаемый, версия соответствует назначенному каналу.
Если вам нужно установить не только сам интерпретатор, но и весь рабочий набор, не начинайте с глобальной среды пользователя. Сначала создайте каталог проекта и только затем добавляйте пакеты. Это позволит повторить установку на другой машине и понять, где именно возник сбой.
Разведите arm64, Intel и внешние зависимости
На Mac с Apple Silicon недостаточно увидеть слово «macOS» в информации о системе. Нужно проверить всю цепочку:
- архитектуру самого Mac;
- архитектуру бинарника Julia;
- архитектуру пакета или
artifact; - архитектуру внешних программ и библиотек C или Fortran;
- режим терминала — нативный или запущенный через Rosetta.
artifact, динамической библиотеки или внешнего исполняемого файла. [Документация Julia об Artifacts](https://pkgdocs.julialang.org/v1.5/artifacts/) описывает их как доставляемые бинарные зависимости, поэтому их нельзя считать обычным исходным кодом, который всегда соберётся одинаково.
Проведите проверку до установки тяжёлых научных пакетов:
uname -m
file "$(which julia)"
arch
julia -e 'println(Sys.ARCH); versioninfo()'Интерпретируйте результат вместе с путями. Если which julia указывает на старую установку, сначала исправьте источник команды. Если Julia arm64 запускает Intel-зависимость, найдите нативную сборку или проверьте официальные инструкции конкретного пакета.
**Важно.** Rosetta — не универсальное исправление. Используйте изолированный Intel-сценарий только тогда, когда необходимая зависимость действительно не имеет рабочего arm64-варианта и проект допускает такой компромисс. Смешивание архитектур в одном окружении усложняет диагностику и снижает ценность проверки воспроизводимости.
Как читать симптомы архитектурной ошибки
| Наблюдение | Вероятный уровень проблемы | Безопасное действие |
|---|---|---|
| Julia запускается, но путь указывает на старую установку | PATH или дублирующий вход | Зафиксировать which julia, затем исправить порядок путей |
Пакет разрешается, но artifact не загружается или не открывается | Платформенная сборка или бинарная зависимость | Проверить arm64-поддержку пакета и его артефактов |
| Компиляция C или Fortran завершается ошибкой | Локальный компилятор, заголовки или архитектура | Разделить ошибку компилятора и ошибку Julia-пакета |
| Внешний инструмент не найден | Неверный PATH или отсутствие программы | Проверить команду отдельно от Julia |
| Проект запускается только в терминале под Rosetta | Зависимость не готова к arm64 либо конфликт окружения | Создать отдельный совместимый профиль, не менять основной проект |
Устраните конфликт juliaup, Shell и PATH
Разные оболочки могут читать разные файлы конфигурации. Терминал, VS Code и удалённая сессия SSH иногда запускают не один и тот же PATH. Поэтому сообщение «Julia установлена» ничего не говорит о том, какую именно Julia получает проект.
Сначала соберите факты:
type -a julia
which -a julia
juliaup status
julia --version
echo "$PATH"Затем действуйте в таком порядке:
- определите, какой файл оболочки изменяет
PATH; - выясните, принадлежит ли найденная команда
juliaup; - назначьте нужный стабильный канал через штатные команды
juliaup; - перезапустите оболочку и повторите проверку;
- отдельно проверьте тот же путь в VS Code, Notebook или SSH.
which julia.
Оценка готовности здесь простая: одна активная команда Julia, понятный канал juliaup, ожидаемая архитектура и одинаковый результат в том интерфейсе, где будет выполняться работа. Если терминал и VS Code показывают разные версии, установка ещё не завершена с точки зрения проекта.
Проверьте сеть до диагностики пакетов
Ошибка при Pkg.instantiate() не всегда означает несовместимость Julia 1.13. Запросы могут проходить несколько уровней:
- доступ к реестру пакетов;
- обращение к серверу пакетов;
- загрузка Git-репозитория;
- получение бинарного
artifact; - локальная сборка зависимости;
- запуск уже установленной библиотеки.
mkdir julia-113-check
cd julia-113-check
julia --project=.В REPL:
using Pkg
Pkg.activate(".")
Pkg.add("Example")
Pkg.instantiate()Если ошибка появляется до разрешения зависимостей, проверяйте доступ к официальным доменам Julia и HTTPS-настройки. Документация Pkg о протоколе работы описывает получение реестров, пакетов и артефактов. Ошибка Git, ошибка сертификата и отсутствие arm64-артефакта требуют разных решений.
В университетской сети прокси, фильтрацию HTTPS и сертификаты должен проверять сетевой администратор. Не отключайте проверку сертификатов и не обходите защиту случайным зеркалом ради того, чтобы одна установка завершилась. Для отчёта сохраните первый содержательный текст ошибки, канал Julia, архитектуру и момент сбоя. Повторные строки после первичной ошибки часто только маскируют источник проблемы.
Минимальная проверка должна включать загрузку небольшого пакета и выполнение короткой команды внутри активированного проекта. Если она проходит, это подтверждает только базовый путь к реестру и пакету, но не совместимость всей научной цепочки. Сложный пакет с локальной компиляцией проверяйте отдельно и по его официальной документации.
Перенесите проект через Project.toml и Manifest.toml
Глобальная среда удобна для краткого эксперимента, но не для диссертационной работы или общего проекта лаборатории. Для каждой задачи создайте собственное окружение:
mkdir project-julia-113
cd project-julia-113
julia --project=.В Julia:
using Pkg
Pkg.activate(".")
Pkg.add(["CSV", "DataFrames"])
Pkg.instantiate()
Pkg.status()Названия пакетов здесь приведены как пример минимальной проверки; для реальной задачи используйте список из проекта и сверяйте поддержку конкретных версий с документацией авторов.
Project.toml описывает прямые зависимости, а Manifest.toml фиксирует разрешённое состояние окружения. [Описание формата TOML и проектных файлов в документации Pkg](https://pkgdocs.julialang.org/dev/toml-files/) помогает отличить декларацию зависимостей от полного разрешённого состояния. Не заменяйте старый Manifest.toml новым в том же каталоге: сначала создайте копию, которая будет доступна только для чтения.
Для старого проекта применяйте такой порядок:
- архивируйте исходный каталог;
- сохраните прежний канал Julia и старый
Manifest.toml; - скопируйте проект в отдельный каталог миграции;
- активируйте Julia 1.13 через
juliaup; - выполните
instantiate; - сравните версии прямых и транзитивных пакетов;
- запустите контрольную задачу и сопоставьте результаты.
Для временного эксперимента допустима отдельная активированная среда без добавления её в общий каталог пользователя. Для диссертации, курса или проекта лаборатории храните Project.toml и нужный Manifest.toml рядом с кодом, но не смешивайте их с большими входными данными и сгенерированными результатами.
С Linux-проектом можно совместно использовать исходный код и описание зависимостей, но нельзя заранее считать Manifest переносимым без проверки. Платформенные артефакты, системные библиотеки, пути к файлам и внешние команды могут отличаться. Общими должны быть логика проекта и зафиксированные требования, а конкретное разрешённое окружение следует подтвердить на каждой платформе.
Проведите научную, а не только техническую приёмку
Сообщение using PackageName прошло успешно — это лишь один критерий. Перед допуском среды проверьте:
- запуск из чистого каталога с проектом;
- полную загрузку зависимостей;
- чтение входных файлов;
- запись результатов в ожидаемом формате;
- создание графика и его экспорт;
- работу через VS Code или Notebook, если этот интерфейс нужен;
- продолжение или корректное восстановление после разрыва удалённой сессии;
- контрольный журнал выполнения без превращения его в универсальную оценку производительности.
Для удалённой проверки заранее сохраните команды подключения и определите, где находятся временные данные. Не оставляйте персональные или ещё не опубликованные данные на машине после завершения теста. Если исследователю нужны графические приложения и терминал, список проверки должен включать оба интерфейса, а не только SSH.
Условия решения
- Если Julia 1.13 запускается как arm64, окружение устанавливается, контрольные результаты совпадают, а графика и экспорт проходят проверку, то продолжайте миграцию.
- Если пакеты устанавливаются, но результаты отличаются, то вернитесь к старому Manifest, зафиксируйте различие и проверьте изменения пакетов, численных библиотек и параметров.
- Если проблема относится только к старой внешней зависимости без arm64-пути, то сохраняйте основной проект нативным и создайте отдельный совместимый профиль; не смешивайте его с новой средой.
- Если сеть блокирует реестр или artifact, то остановите установку и передайте администратору точный адрес, тип ошибки и сертификатный контекст.
- Если проект нужен только для воспроизведения опубликованного результата, то не объявляйте миграцию успешной до совпадения ключевых файлов, графиков и численных показателей.
- Если доступного Apple Silicon Mac нет, то проведите эту же приёмку на удалённом Mac, прежде чем покупать оборудование или менять рабочую инфраструктуру.
Частые вопросы перед переносом
Стоит ли выбирать стабильную Julia 1.13 вместо LTS?
Для нового проекта выбирайте стабильный канал, если пакетный стек и методика готовы к нему. LTS разумнее для длительно поддерживаемой системы, где важнее консервативное обновление. Старую опубликованную работу не переводите автоматически: сначала сохраните исходный канал и воспроизведите контрольный результат в отдельной среде Julia 1.13.
Нужна ли Rosetta на Apple Silicon?
Нет, не по умолчанию. Сначала используйте нативную Julia для Apple Silicon и проверьте arm64-зависимости. Rosetta оправдана только для конкретного старого внешнего бинарника или пакета, для которого нет рабочего нативного варианта. Такой путь должен быть изолирован и зафиксирован в документации проекта.
Запустится ли графическая научная задача на удалённом Mac?
Запуститься может, но REPL-проверки недостаточно. Проверьте выбранный графический backend, работу VS Code или Notebook, экспорт изображения и поведение при закрытии соединения. Для длинной задачи используйте журнал, сохранение промежуточного результата и повторное подключение, а не рассчитывайте на постоянно открытое окно VNC.
Можно ли использовать один Manifest для Linux и macOS?
Не всегда. Исходный Project.toml может быть общим, но бинарные артефакты и системные зависимости платформенные. Если разрешённое окружение различается, храните версии манифестов отдельно и явно выбирайте нужный файл. Это надёжнее, чем постоянно перегенерировать единственный Manifest при переключении машины.
Когда перенос нужно остановить?
Остановитесь, если не удаётся определить архитектуру Julia, источник команды или первый значимый сетевой сбой; если пакет загружается, но выдаёт непроверяемые результаты; если графика и экспорт не соответствуют методике; либо если сохранение старой среды невозможно. В этих случаях временно оставайтесь на исходном канале и оформите отдельный план совместимости.
Для короткой проверки не обязательно сразу покупать отдельный компьютер. Когда вы уже подготовили Project.toml, Manifest.toml, список зависимостей и контрольную задачу, временная аренда Mac через MACGPU позволяет проверить Julia 1.13 на реальной Apple Silicon-среде, пройти ту же приёмку и только после этого решить, нужна ли постоянная машина, двойная инфраструктура или дальнейшая аренда. Сравните сценарий с условиями временной аренды Mac, но принимайте решение по результатам проекта: успешный запуск REPL сам по себе не подтверждает научную воспроизводимость.