3. Управление пакетами

Существует два способа добавления пакетов: с помощью команды add или команды dev. Наиболее часто используется add, и ее применение описывается первым.

Удалить пакеты из текущего проекта можно с помощью команды pkg> rm Package. При этом будут удалены только те пакеты, которые существуют в проекте. Чтобы удалить пакет, который существует только как зависимость, используйте pkg> rm --manifest DepPackage. Обратите внимание, что в этом случае будут удалены все пакеты, которые (рекурсивно) зависят от DepPackage.

Рекомендуется обновлять выходящие новые версии пакетов. Просто вызовите up, чтобы попытаться обновить все зависимости проекта до последней совместимой версии. Иногда это совсем не то, что вам нужно. Вы можете указать подмножество зависимостей для обновления, передав их в качестве аргументов в up, например:

Так можно обновить только пакет Example. Если вы также хотите разрешить обновление зависимостей Example (за исключением пакетов, которые находятся в проекте), можно передать флаг --preserve=direct.

А если вы также хотите разрешить обновление зависимостей Example, которые находятся в проекте, используйте --preserve=none.

Закрепленный пакет никогда не обновляется. Пакет можно закрепить с помощью pin, например:

Обратите внимание на символ канцелярской кнопки ⚲, показывающий, что пакет закреплен. Удаление закрепления выполняется с помощью команды free

Тесты для пакета можно запускать с помощью команды test:

Шаг сборки пакета автоматически запускается при первой установке пакета. Выходные данные процесса сборки направляются в файл. Для запуска шага сборки пакета явным образом используется команда build:

Среда состоит из набора взаимно совместимых пакетов. Иногда может возникнуть ситуация, когда два пакета, которые вы хотели бы использовать одновременно, имеют несовместимые требования. В таких случаях возникает ошибка «Невыполнимые требования»:

Это сообщение означает, что в пакете с именем D присутствует конфликт версий. Даже если вы никогда не добавляли (add) D напрямую, такая ошибка может возникнуть, если пакет D требуется другим пакетам, которые вы пытаетесь использовать.

Сообщение об ошибке содержит много важной информации. Возможно, проще всего выполнять интерпретацию по частям:

означает, что пакет D имеет три выпущенные версии — v0.1.0, v0.2.0 и v0.2.1. Вы также можете не устанавливать его вообще. Каждый из этих вариантов может иметь различные последствия для набора других пакетов, которые могут быть установлены.

Важно обратить внимание на штриховые символы (вертикальные и горизонтальные линии) и их отступы. Вместе они соединяют сообщения с конкретными пакетами. Например, правый штрих ├─ указывает на то, что сообщение справа от него (possible versions...) связано с пакетом, на который указывает его вертикальный штрих (D). Этот же принцип применим и к следующей строке:

Вертикальный штрих здесь также выровнен с D, и, таким образом, это сообщение относится к пакету D. В частности, существует другой пакет B, который зависит от версии v0.1.0 пакета D. Обратите внимание, что это не самая новая версия пакета D.

Далее следует информация о пакете B:

Две строки под первой имеют вертикальный штрих, который выравнивается с B, и, таким образом, они предоставляют информацию о пакете B. Они сообщают, что пакет B имеет только один выпуск v1.0.0. Вы не указали конкретную версию пакета B (restricted to versions * означает, что подойдет любая версия), но explicit requirement означает, что вы попросили, чтобы пакет B стал частью вашей среды, например с помощью pkg> add B. Возможно, вы уже запрашивали пакет B ранее, и это требование все еще активно.

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

Здесь снова вертикальный штрих выравнивается с пакетом D: это означает, что пакет D требуется также для другого пакета, C. Для пакета C требуется версия v0.2.0 пакета D, и это конфликтует с потребностью пакета B в версии v0.1.0 пакета D. Это и объясняет конфликт.

Но подождите, спросите вы, что такое пакет C и зачем он вообще нужен? Проблема представлена в следующих нескольких строках:

Они содержат дополнительную информацию о пакете C, показывая, что у него есть 3 выпущенные версии: v0.1.0, v0.1.1 и v0.2.0. Кроме того, C требуется другому пакету A. Действительно, требования пакета A таковы, что нам требуется версия v0.2.0 пакета C. Источник пакета A раскрывается в следующих строках:

Итак, мы видим, что пакет A требовался явным образом, и в данном случае это связано с тем, что мы пытались добавить (add) его в среду.

В итоге мы явным образом хотели использовать пакеты A и B, но это привело к конфликту для пакета D. Причина заключалась в том, что для пакетов B и C требуются конфликтующие версии пакета D. Хотя пакет C не является тем, что нам было нужно явным образом, он был необходим для пакета A.

Существует несколько вариантов исправления таких ошибок:

По мере обновления пакетов и удаления проектов установленные версии пакетов и артефакты, которые когда-то использовались, неизбежно устаревают и не используются ни в одном из существующих проектов. Pkg ведет журнал всех использовавшихся проектов, поэтому он может просмотреть журнал и определить, какие проекты еще существуют и какие пакеты или артефакты использовались в этих проектах. Если пакет или артефакт не помечен как используемый в каком-либо проекте, он добавляется в список ненужных. Пакеты и артефакты, находящиеся в списке ненужных в течение 30 дней без повторного использования, удаляются из системы при следующей сборке мусора. Этот временной режим настраивается с помощью именованного аргумента collect_delay для Pkg.gc(). Если задано значение 0, все, что в данный момент не используется, будет немедленно собрано, а список ненужных пакетов и артефактов будет полностью пропущен. Если у вас мало места на диске и вы хотите удалить как можно больше неиспользуемых пакетов и артефактов, вы можете попробовать сделать это, но если эти версии понадобятся снова, вам придется загрузить их повторно. Чтобы запустить стандартную сборку мусора с аргументами по умолчанию, просто используйте команду gc в REPL pkg>:

Обратите внимание, что удаляются только пакеты из каталога ~/.julia/packages.

В автономном режиме Pkg пытается выполнить как можно больше задач без подключения к Интернету. Например, при добавлении пакета Pkg учитывает только те версии, которые уже скачаны в разрешении версий.

Для работы в автономном режиме используйте import Pkg; Pkg.offline(true) или задайте переменной среды JULIA_PKG_OFFLINE значение "true".

При добавлении нового зарегистрированного пакета обычно происходят три вещи:

Реестр General и большинство содержащихся в нем пакетов разрабатываются на сайте GitHub, а данные артефактов размещаются на различных платформах. Если сетевое подключение к GitHub и AWS S3 нестабильно, устанавливать или обновлять пакеты обычно не рекомендуется. Но возможность использования клиента/сервера в Pkg улучшает работу в том смысле, что:

По умолчанию клиент выполняет до 8 одновременных запросов к серверу. Это значение можно задать с помощью переменной среды JULIA_PKG_CONCURRENT_DOWNLOADS.

Начиная с Julia 1.5 https://pkg.julialang.org, предоставляемый организацией JuliaLang, используется в качестве сервера Pkg по умолчанию. В большинстве случаев работа должна быть прозрачной, но пользователи по-прежнему могут задавать или отменять вышестоящий сервер Pkg с помощью переменной среды JULIA_PKG_SERVER.

Поясним, что сервер Pkg не предоставляет некоторые источники:

Сведения о развертывании сервера Pkg см. в разделе о PkgServer.jl.