Загрузка кода

Среда проекта образуется из каталога, содержащего файл проекта с именем Project.toml, и необязательного файла манифеста с именем Manifest.toml. Эти файлы также могут иметь имена JuliaProject.toml и JuliaManifest.toml; в этом случае файлы Project.toml и Manifest.toml игнорируются. Это позволяет одновременно использовать инструменты, полагающиеся на файлы с именами Project.toml и Manifest.toml. Однако для проектов исключительно на Julia имена Project.toml и Manifest.toml предпочтительнее.

Схемы корней, графа и путей среды проекта определяются следующим образом.

Схема корней среды определяется содержимым файла проекта, в частности его элементами name и uuid верхнего уровня и разделом [deps] (все они являются необязательными). Рассмотрим следующий пример файла проекта для вымышленного приложения App, которое описывалось выше.

Этот файл проекта предполагает следующую схему корней, представленную в виде словаря Julia.

При такой схеме корней оператор import Priv в коде App предписывает Julia выполнить поиск roots[:Priv], в результате чего будет получено значение ba13f791-ae1d-465a-978b-69c3ad90f72b — UUID пакета Priv, который должен быть загружен в данном контексте. Идентификатор UUID определяет то, какой пакет Priv должен загружаться и использоваться при вычислении оператора import Priv в главном приложении.

Граф зависимостей среды проекта определяется содержимым файла манифеста при его наличии. Если файла манифеста нет, граф пуст. В файле манифеста имеется отдельный раздел для каждой прямой или косвенной зависимости проекта. Для каждой зависимости в файле указываются UUID пакета и хэш дерева исходного кода или явный путь к исходному коду. Рассмотрим следующий пример файла манифеста для приложения App:

В этом файле манифеста полностью описывается возможный граф зависимостей для проекта App.

Граф зависимостей, представленный в виде словаря, выглядит так:

При таком графе (graph) зависимостей, когда Julia встречает выражение import Priv в пакете Pub с UUID c07ecb7d-0dc9-4db7-8803-fadaaeaf08e1, производится следующий поиск:

В результате возвращается значение 2d15fe94-a1f7-436c-a4d8-07a9a496e01c, а это означает, что в контексте пакета Pub выражение import Priv ссылается на общедоступный пакет Priv, а не на частный, от которого приложение зависит напрямую. Именно таким образом по имени Priv в главном проекте можно ссылаться на пакеты, отличные от тех, на которые это имя указывает в зависимостях, благодаря чему в системе пакетов становятся возможными одинаковые имена.

Что произойдет при вычислении выражения import Zebra в основном коде App? Так как пакет Zebra не указан в файле проекта, импорт завершится ошибкой несмотря на то, что Zebra имеется в файле манифеста. Более того, если бы оператор import Zebra использовался в общедоступном пакете Priv с UUID 2d15fe94-a1f7-436c-a4d8-07a9a496e01c, он также завершился бы ошибкой, так как у этого пакета Priv нет объявленных зависимостей в файле манифеста и поэтому он не может загружать другие пакеты. Пакет Zebra может загружаться только пакетами, для которых он явно указан как зависимость в файле манифеста, а именно пакетом Pub и одним из пакетов Priv.

Схема путей среды проекта извлекается из файла манифеста. Путь к пакету с идентификатором uuid и именем X определяется по следующим правилам (в указанном порядке).

Если какое-либо из этих условий выполнено, путем к точке входа в исходный код будет либо полученный результат, либо путь относительно этого результата с добавлением src/X.jl. В противном случае пути, соответствующего идентификатору uuid, нет. Если при загрузке пакета X не удается найти путь к исходному коду, поиск завершается сбоем и пользователю может быть предложено установить соответствующую версию пакета или исправить ситуацию иным образом (например, объявить X как зависимость).

В примере файла манифеста выше путь к первому пакету Priv (с UUID ba13f791-ae1d-465a-978b-69c3ad90f72b) определяется следующим образом: Julia ищет раздел этого пакета в файле манифеста, находит элемент path, ищет путь deps/Priv относительно каталога проекта App (допустим, что код App находится по пути /home/me/projects/App), находит каталог /home/me/projects/App/deps/Priv и поэтому загружает пакет Priv из него.

Если же требовалось бы загрузить другой пакет Priv (с UUID 2d15fe94-a1f7-436c-a4d8-07a9a496e01c), среда Julia нашла бы его раздел в манифесте, в котором, однако, нет элемента path, но есть элемент git-tree-sha1. Поэтому было бы вычислено значение slug для этой пары UUID и хэша SHA-1 и получен результат HDkrT (как именно производится это вычисление, неважно, но функция согласованная и детерминированная). Это означает, что путем к пакету Priv будет путь packages/Priv/HDkrT/src/Priv.jl в одном из хранилищ пакетов. Допустим, переменная DEPOT_PATH содержит значение ["/home/me/.julia", "/usr/local/julia"]. В этом случае Julia проверяет, существуют ли следующие пути:

Затем Julia пытается загрузить общедоступный пакет Priv из файла packages/Priv/HDKrT/src/Priv.jl в хранилище, в котором найден первый из этих путей.

Ниже показана возможная схема путей для примера среды проекта App в том виде, в каком она представлена в манифесте для приведенного выше графа зависимостей, после поиска в локальной файловой системе.

В схеме из примера есть расположения пакетов трех разных типов (первое и третье расположения являются частью пути загрузки по умолчанию).

Каталоги пакетов — это более простой тип среды, не позволяющий разрешать конфликты имен. В каталоге пакетов набор пакетов верхнего уровня — это набор вложенных каталогов, которые «выглядят» как пакеты. Пакет X существует в каталоге пакетов, если в этом каталоге есть один из следующих файлов точки входа:

То, какие зависимости может импортировать пакет в каталоге пакетов, определяется наличием файла проекта в пакете.

Схема корней определяется путем анализа содержимого каталога проектов и формирования списка всех имеющихся пакетов. Кроме того, каждому пакету, найденному в папке X, назначается идентификатор UUID следующим образом.

Граф зависимостей каталога пакетов определяется наличием и содержимым файла проекта во вложенном каталоге каждого пакета. При этом действуют следующие правила.

Предположим, каталог пакетов имеет следующую структуру и содержимое:

В виде словаря соответствующая структура корней будет представлена так:

В виде словаря соответствующая структура графа будет представлена так:

Обратите внимание на ряд важных правил.

Посмотрим, как эти правила применяются на практике в нашем примере.

Схема путей в каталоге пакетов устроена очень просто: в ней имена вложенных каталогов сопоставляются с путями точек входа. Иными словами, если бы путь к каталогу проекта в нашем примере имел вид /home/me/animals, то схему paths можно было бы представить таким словарем:

Так как все пакеты в среде каталога пакетов по определению являются вложенными каталогами с соответствующими файлами точек входа, элементы их схемы paths всегда имеют такую форму.

Третий и последний тип среды — это такой, в котором среды других типов накладываются друг на друга, образуя единую среду, где доступны пакеты каждой из составляющих сред. Такие составные среды называются стеками сред. В глобальной переменной Julia LOAD_PATH определен стек сред, в котором работает процесс Julia. Чтобы процесс Julia имел доступ к пакетам только из одного проекта или каталога пакетов, не указывайте в LOAD_PATH другие среды. Однако зачастую полезно иметь доступ к каким-либо инструментам — стандартным библиотекам, профилировщикам, отладчикам, вспомогательным программам и т. д. — даже если они не являются зависимостями текущего проекта. Если добавить среду с этими инструментами в путь загрузки, то они сразу же будут доступны в коде верхнего уровня, так что добавлять их в проект не нужно.

Структуры данных корней, графа и путей, принадлежащие составляющим стека сред, объединяются очень просто — как словари, причем в случае совпадения ключей приоритет отдается более ранним записям. Иными словами, если имеется стек stack = [env₁, env₂, …], то происходит следующее.

Переменные rootsᵢ, graphᵢ и pathsᵢ с нижними индексами соответствуют средам envᵢ с нижними индексами, входящими в stack. Функция reverse применяется по той причине, что при совпадении ключей в словарях, переданных в качестве аргументов в функцию merge, приоритет отдается последнему аргументу, а не первому. У такого подхода есть несколько заслуживающих внимания особенностей.

Так как основная среда — это обычно среда текущего проекта, а более поздние среды в стеке содержат дополнительные инструменты, такой компромисс вполне оправдан: лучше, чтобы перестали работать инструменты разработки, чем весь проект. Как правило, при возникновении таких несовместимостей необходимо обновить инструменты разработки до версий, совместимых с главным проектом.

Расширение пакета — это модуль, который автоматически загружается при загрузке определенного набора других пакетов («зависимостей расширения») в текущем сеансе Julia. Зависимости расширения — это подмножество других пакетов, перечисленных в разделе [weakdeps] файла проекта. Расширения определяются в файле проекта в разделе [extensions]:

Ключи в разделе extensions — это имена расширений. Расширение загружается при загрузке всех пакетов, указанных в правой части (зависимостей расширения). Если у расширения всего одна зависимость, список зависимостей для краткости можно записать в виде строки. Точка входа для расширения FooExt находится в ext/FooExt.jl или ext/FooExt/FooExt.jl. Содержимое расширения часто имеет такую структуру:

Когда пакет с расширениями добавляется в среду, разделы weakdeps и extensions сохраняются в файле манифеста в разделе для этого пакета. Правила поиска зависимостей для пакета такие же, как и для его «родителя», за тем исключением, что зависимости расширения в списке также считаются зависимостями.

Предпочтения — это словари метаданных, влияющих на поведение пакетов в среде. Система предпочтений поддерживает чтение предпочтений во время компиляции. Это означает, что перед загрузкой кода необходимо убедиться в том, что сборка файлов предварительной компиляции, выбранных Julia, была выполнена с предпочтениями текущей среды. Общедоступный API для изменения предпочтений содержится в пакете Preferences.jl. Предпочтения хранятся в виде словарей TOML в файле (Julia)LocalPreferences.toml рядом с текущим активным проектом. При экспорте предпочтение переносится в файл (Julia)Project.toml. Замысел в том, чтобы общие проекты могли иметь общие предпочтения, но пользователи могли переопределять их с помощью собственных настроек в файле LocalPreferences.toml, который, как следует из его имени, должен добавляться в файл .gitignore.

Предпочтения, к которым происходит обращение во время компиляции, автоматически помечаются как предпочтения времени компиляции. Любое их изменение вынудит компилятор Julia перекомпилировать все кэшированные файлы предварительной компиляции (.ji и соответствующие файлы .so, .dll или .dylib) для данного модуля. Для этого при компиляции хэш всех предпочтений времени компиляции сериализуется, а затем при поиске нужных файлов проверяется на соответствие текущей среде.

Для предпочтений можно задать значения по умолчанию на уровне хранилища; если пакет Foo устанавливается в глобальной среде и имеет заданные предпочтения, они применяются при условии, что глобальная среда включена в LOAD_PATH. Предпочтения, относящиеся к средам выше в стеке сред, переопределяются записями более низкого уровня в пути загрузки вплоть до текущего активного проекта. Это позволяет существовать предпочтениям по умолчанию на уровне проекта, причем при наследовании для активных проектов они могут объединяться или даже полностью перезаписываться. Подробные сведения о том, как разрешить или запретить объединение предпочтений, см. в docstring функции Preferences.set_preferences!().