Engee
Личный кабинет

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

Добавление пакетов

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

Добавление зарегистрированных пакетов

В REPL Pkg пакеты можно добавить с помощью команды add, за которой следует имя пакета, например:

(@v1.8) pkg> add JSON
  Installing known registries into `~/`
   Resolving package versions...
   Installed Parsers ─ v2.4.0
   Installed JSON ──── v0.21.3
    Updating `~/.julia/environments/v1.8/Project.toml`
  [682c06a0] + JSON v0.21.3
    Updating `~/environments/v1.9/Manifest.toml`
  [682c06a0] + JSON v0.21.3
  [69de0a69] + Parsers v2.4.0
  [ade2ca70] + Dates
  [a63ad114] + Mmap
  [de0858da] + Printf
  [4ec0a83e] + Unicode
Precompiling environment...
  2 dependencies successfully precompiled in 2 seconds

Здесь мы добавили пакет Example в текущую среду (которая является средой @v1.8 по умолчанию). В этом примере мы используем актуальную установку Julia и в первый раз добавляем пакет с помощью Pkg. По умолчанию Pkg устанавливает реестр General и использует его для поиска пакетов, запрашиваемых для включения в текущую среду. В обновлении статуса слева отображается краткая форма UUID пакета, затем имя пакета и версия. Наконец, установленные пакеты предварительно компилируются.

Можно добавить несколько пакетов одной командой в виде pkg> add A B C.

В выходных данных состояния приводятся пакеты, которые вы добавили сами, в данном случае JSON:

(@v1.8) pkg> st
    Status `~/.julia/environments/v1.8/Project.toml`
  [682c06a0] JSON v0.21.3

В состоянии манифеста отображаются все пакеты в среде, включая рекурсивные зависимости:

(@v1.8) pkg> st -m
Status `~/environments/v1.9/Manifest.toml`
  [682c06a0] JSON v0.21.3
  [69de0a69] Parsers v2.4.0
  [ade2ca70] Dates
  [a63ad114] Mmap
  [de0858da] Printf
  [4ec0a83e] Unicode

Поскольку стандартные библиотеки (например, Dates) входят в состав Julia, они не имеют версии.

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

julia> using JSON

julia> JSON.json(Dict("foo" => [1, "bar"])) |> print
{"foo":[1,"bar"]}

Могут быть загружены только пакеты, добавленные с помощью add (это пакеты, которые отображаются при использовании st в REPL Pkg). Пакеты, которые добавляются только в качестве зависимостей (например, пакет Parsers выше), не могут быть загружены.

Для установки конкретной версии пакета можно добавить номер версии после символа @ к имени пакета:

(@v1.8) pkg> add JSON@0.21.1
   Resolving package versions...
    Updating `~/.julia/environments/v1.8/Project.toml`
⌃ [682c06a0] + JSON v0.21.1
    Updating `~/environments/v1.9/Manifest.toml`
⌃ [682c06a0] + JSON v0.21.1
⌅ [69de0a69] + Parsers v1.1.2
  [ade2ca70] + Dates
  [a63ad114] + Mmap
  [de0858da] + Printf
  [4ec0a83e] + Unicode
        Info Packages marked with ⌃ and ⌅ have new versions available, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated -m`

Как было показано выше, Pkg выдает некоторую информацию, когда не установлена последняя версия пакета.

Если для версии указаны не все три числа, например 0.21, будет установлена последняя зарегистрированная версия 0.21.x.

Если ветвь (или определенная фиксация) пакета Example содержит исправление, которое еще не включено в зарегистрированную версию, можно явным образом отслеживать эту ветвь (или фиксацию), добавив #branchname (или #commitSHA1) к имени пакета:

(@v1.8) pkg> add Example#master
     Cloning git-repo `https://github.com/JuliaLang/Example.jl.git`
   Resolving package versions...
    Updating `~/.julia/environments/v1.8/Project.toml`
  [7876af07] + Example v0.5.4 `https://github.com/JuliaLang/Example.jl.git#master`
    Updating `~/environments/v1.9/Manifest.toml`
  [7876af07] + Example v0.5.4 `https://github.com/JuliaLang/Example.jl.git#master`

Теперь в выходных данных состояния отображается, что мы отслеживаем ветвь master пакета Example. При обновлении пакетов обновления извлекаются из этой ветви.

Если бы мы вместо имени ветви указали идентификатор фиксации, например add Example#025cf7e, мы бы закрепили пакет к этой фиксации. Это связано с тем, что идентификатор фиксации всегда указывает на одно и то же, в отличие от ветви, которая может обновляться.

Чтобы вернуться к отслеживанию версии реестра Example, используется команда free:

(@v1.8) pkg> free Example
   Resolving package versions...
   Installed Example ─ v0.5.3
    Updating `~/.julia/environments/v1.8/Project.toml`
  [7876af07] ~ Example v0.5.4 `https://github.com/JuliaLang/Example.jl.git#master` ⇒ v0.5.3
    Updating `~/environments/v1.9/Manifest.toml`
  [7876af07] ~ Example v0.5.4 `https://github.com/JuliaLang/Example.jl.git#master` ⇒ v0.5.3

Добавление незарегистрированных пакетов

Если пакет отсутствует в реестре, его можно добавить, указав URL-адрес репозитория Git:

(@v1.8) pkg> add https://github.com/fredrikekre/ImportMacros.jl
     Cloning git-repo `https://github.com/fredrikekre/ImportMacros.jl`
   Resolving package versions...
    Updating `~/.julia/environments/v1.8/Project.toml`
  [92a963f6] + ImportMacros v1.0.0 `https://github.com/fredrikekre/ImportMacros.jl#master`
    Updating `~/environments/v1.9/Manifest.toml`
  [92a963f6] + ImportMacros v1.0.0 `https://github.com/fredrikekre/ImportMacros.jl#master`

Зависимости незарегистрированного пакета (здесь MacroTools) были установлены. Для незарегистрированных пакетов можно указать имя ветви (или SHA1 фиксации) для отслеживания с помощью #, как и для зарегистрированных пакетов.

Чтобы добавить пакет с помощью протокола git на основе SSH, придется использовать кавычки, поскольку URL-адрес содержит @. Например,

(@v1.8) pkg> add "git@github.com:fredrikekre/ImportMacros.jl.git"
    Cloning git-repo `git@github.com:fredrikekre/ImportMacros.jl.git`
   Updating registry at `~/.julia/registries/General`
  Resolving package versions...
Updating `~/.julia/environments/v1/Project.toml`
  [92a963f6] + ImportMacros v1.0.0 `git@github.com:fredrikekre/ImportMacros.jl.git#master`
Updating `~/.julia/environments/v1/Manifest.toml`
  [92a963f6] + ImportMacros v1.0.0 `git@github.com:fredrikekre/ImportMacros.jl.git#master`

Добавление пакета в подкаталоге репозитория

Если пакет, который вы хотите добавить по URL-адресу, не находится в корне репозитория, вам нужно передать этот подкаталог с помощью :. Например, чтобы добавить пакет SnoopCompileCore в репозитории SnoopCompile, выполните следующее:

pkg> add https://github.com/timholy/SnoopCompile.jl.git:SnoopCompileCore
    Cloning git-repo `https://github.com/timholy/SnoopCompile.jl.git`
   Resolving package versions...
    Updating `~/.julia/environments/v1.8/Project.toml`
  [e2b509da] + SnoopCompileCore v2.9.0 `https://github.com/timholy/SnoopCompile.jl.git:SnoopCompileCore#master`
    Updating `~/.julia/environments/v1.8/Manifest.toml`
  [e2b509da] + SnoopCompileCore v2.9.0 `https://github.com/timholy/SnoopCompile.jl.git:SnoopCompileCore#master`
  [9e88b42a] + Serialization

Добавление локального пакета

Вместо указания URL-адреса репозитория для добавления (add) можно указать локальный путь к репозиторию git. Это работает аналогично добавлению URL-адреса. Локальный репозиторий будет отслеживаться (в определенной ветви), и при обновлении пакетов будут извлекаться обновления из этого локального репозитория.

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

Разработка пакетов

При использовании только add среда всегда находится в «воспроизводимом состоянии». Другими словами, пока используемые репозитории и реестры остаются доступными, можно получить точное состояние всех зависимостей в среде. Преимущество этого способа заключается в том, что вы можете отправить свою среду (Project.toml и Manifest.toml) кому-то другому, и он сможет с помощью Pkg.instantiate создать экземпляр этой среды в том же состоянии, в котором она была у вас локально. Однако при разработке пакета удобнее загружать пакеты в их текущем состоянии по определенному пути. Это можно сделать с помощью команды dev.

Давайте попробуем разработать (dev) зарегистрированный пакет:

(@v1.8) pkg> dev Example
  Updating git-repo `https://github.com/JuliaLang/Example.jl.git`
   Resolving package versions...
    Updating `~/.julia/environments/v1.8/Project.toml`
  [7876af07] + Example v0.5.4 `~/.julia/dev/Example`
    Updating `~/.julia/environments/v1.8/Manifest.toml`
  [7876af07] + Example v0.5.4 `~/.julia/dev/Example`

Команда dev получает полный клон пакета по пути ~/.julia/dev/ (путь можно изменить, задав переменную среды JULIA_PKG_DEVDIR, по умолчанию используется joinpath(DEPOT_PATH[1],"dev")). При импорте Example Julia теперь будет импортировать его из пути ~/.julia/dev/Example, и все локальные изменения, внесенные в файлы по этому пути, отразятся в загружаемом коде. Когда мы использовали add, мы говорили, что отслеживаем репозиторий пакетов. Здесь мы говорим, что отслеживаем сам путь. Обратите внимание, что диспетчер пакетов никогда не будет трогать файлы по отслеживаемому пути. Поэтому вы сами должны извлекать обновления, изменять ветви и т. д. Если мы попытаемся разработать (dev) пакет в какой-то ветви, которая уже существует по пути ~/.julia/dev/, диспетчер пакетов просто повторно использует существующий путь. Если dev используется в локальном пути, то этот путь к пакету записывается и используется при загрузке этого пакета. Путь будет записан относительно файла проекта, если только он не указан как абсолютный путь.

Попробуем изменить файл по пути ~/.julia/dev/Example/src/Example.jl и добавить простую функцию:

plusone(x::Int) = x + 1

Теперь мы можем вернуться в REPL Julia, загрузить пакет и выполнить новую функцию:

julia> import Example
[ Info: Precompiling Example [7876af07-990d-54b4-ab0e-23690620f79a]

julia> Example.plusone(1)
2

Пакет можно загрузить в сеансе Julia только один раз. Если вы уже выполнили import Example в текущем сеансе Julia, потребуется перезапустить Julia, чтобы увидеть изменения для Example. Пакет Revise.jl позволяет существенно упростить эту процедуру, но его настройка не рассматривается в настоящем руководстве.

Чтобы прекратить отслеживание пути и снова применять зарегистрированную версию, используйте free:

(@v1.8) pkg> free Example
   Resolving package versions...
    Updating `~/.julia/environments/v1.8/Project.toml`
  [7876af07] ~ Example v0.5.4 `~/.julia/dev/Example` ⇒ v0.5.3
    Updating `~/.julia/environments/v1.8/Manifest.toml`
  [7876af07] ~ Example v0.5.4 `~/.julia/dev/Example` ⇒ v0.5.3

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

Обратите внимание, что если вы добавите зависимость в пакет, который отслеживает локальный путь, то манифест (который содержит весь граф зависимостей) будет рассинхронизирован с реальным графом зависимостей. Это означает, что пакет не сможет загрузить эту зависимость, поскольку она не записана в манифесте. Чтобы синхронизировать манифест, используйте команду REPL resolve.

Помимо абсолютных путей, add и dev могут принимать относительные пути к пакетам. В этом случае сохраняется относительный путь от активного проекта к пакету. Этот подход полезен, когда относительное расположение отслеживаемых зависимостей важнее, чем их абсолютное расположение. Например, отслеживаемые зависимости могут храниться в каталоге активного проекта. Можно переместить весь каталог, и Pkg все равно сможет найти зависимости, потому что их путь относительно активного проекта сохраняется, даже если их абсолютный путь изменился.

Удаление пакетов

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

Обновление пакетов

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

(@v1.8) pkg> up Example

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

(@v1.8) pkg> up --preserve=direct Example

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

(@v1.8) pkg> up --preserve=none Example

Закрепление пакета

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

(@v1.8) pkg> pin Example
 Resolving package versions...
  Updating `~/.julia/environments/v1.8/Project.toml`
  [7876af07] ~ Example v0.5.3 ⇒ v0.5.3 ⚲
  Updating `~/.julia/environments/v1.8/Manifest.toml`
  [7876af07] ~ Example v0.5.3 ⇒ v0.5.3 ⚲

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

(@v1.8) pkg> free Example
  Updating `~/.julia/environments/v1.8/Project.toml`
  [7876af07] ~ Example v0.5.3 ⚲ ⇒ v0.5.3
  Updating `~/.julia/environments/v1.8/Manifest.toml`
  [7876af07] ~ Example v0.5.3 ⚲ ⇒ v0.5.3

Тестирование пакетов

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

(@v1.8) pkg> test Example
...
   Testing Example
   Testing Example tests passed

Сборка пакетов

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

(@v1.8) pkg> build IJulia
    Building Conda ─→ `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/6e47d11ea2776bc5627421d59cdcc1296c058071/build.log`
    Building IJulia → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/98ab633acb0fe071b671f6c1785c46cd70bb86bd/build.log`

julia> print(read(joinpath(homedir(), ".julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/98ab633acb0fe071b671f6c1785c46cd70bb86bd/build.log"), String))
[ Info: Installing Julia kernelspec in /home/kc/.local/share/jupyter/kernels/julia-1.8

Интерпретация и разрешение конфликтов версий

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

pkg> add A
Unsatisfiable requirements detected for package D [756980fe]:
 D [756980fe] log:
 ├─possible versions are: 0.1.0-0.2.1 or uninstalled
 ├─restricted by compatibility requirements with B [f4259836] to versions: 0.1.0
 │ └─B [f4259836] log:
 │   ├─possible versions are: 1.0.0 or uninstalled
 │   └─restricted to versions * by an explicit requirement, leaving only versions: 1.0.0
 └─restricted by compatibility requirements with C [c99a7cb2] to versions: 0.2.0 — no versions left
   └─C [c99a7cb2] log:
     ├─possible versions are: 0.1.0-0.2.0 or uninstalled
     └─restricted by compatibility requirements with A [29c70717] to versions: 0.2.0
       └─A [29c70717] log:
         ├─possible versions are: 1.0.0 or uninstalled
         └─restricted to versions * by an explicit requirement, leaving only versions: 1.0.0

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

При устранении этих конфликтов сначала подумайте о том, что чем крупнее проект, тем больше вероятность возникновения конфликта. Настоятельно рекомендуется использовать целевые проекты для конкретной задачи, а удаление неиспользуемых зависимостей является хорошим первым шагом при возникновении подобных проблем. Например, распространенной ошибкой является наличие немалого количества пакетов в среде по умолчанию (т. е. (@1.8)), и использование ее в качестве среды для всех задач, для которых вы применяете Julia. Лучше создать отдельный проект для задачи, над которой вы работаете, и свести зависимости в нем к минимуму. Дополнительные сведения см. в разделе Работа со средами.

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

Unsatisfiable requirements detected for package D [756980fe]:
 D [756980fe] log:
 ├─possible versions are: [0.1.0, 0.2.0-0.2.1] or uninstalled

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

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

 ├─restricted by compatibility requirements with B [f4259836] to versions: 0.1.0

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

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

 │ └─B [f4259836] log:
 │   ├─possible versions are: 1.0.0 or uninstalled
 │   └─restricted to versions * by an explicit requirement, leaving only versions 1.0.0

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

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

└─restricted by compatibility requirements with C [c99a7cb2] to versions: 0.2.0 — no versions left

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

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

   └─C [c99a7cb2] log:
     ├─possible versions are: [0.1.0-0.1.1, 0.2.0] or uninstalled
     └─restricted by compatibility requirements with A [29c70717] to versions: 0.2.0

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

       └─A [29c70717] log:
         ├─possible versions are: 1.0.0 or uninstalled
         └─restricted to versions * by an explicit requirement, leaving only versions 1.0.0

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

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

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

  • Попытайтесь обновить пакеты. Возможно, разработчики этих пакетов недавно выпустили новые версии, которые взаимно совместимы.

  • Удалите пакет A или B из среды. Возможно, пакет B остался от вашего предыдущего проекта, и он вам больше не требуется. Если вам не нужны пакеты A и B одновременно, это самый простой способ решить проблему.

  • Попробуйте сообщить о конфликте. В этом случае мы смогли сделать вывод, что для пакета B требуется устаревшая версия пакета D. Таким образом, вы можете сообщить о проблеме в репозитории разработки B.jl и попросить обновленную версию.

  • Попробуйте решить проблему самостоятельно. Решение станет проще, как только вы поймете, что такое файлы Project.toml и как они заявляют о своих требованиях к совместимости. Мы вернемся к этому примеру в разделе Устранение конфликтов.

Сборка старых и неиспользуемых пакетов в мусор

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

(@v1.8) pkg> gc
    Active manifests at:
        `~/BinaryProvider/Manifest.toml`
        ...
        `~/Compat.jl/Manifest.toml`
    Active artifacts:
        `~/src/MyProject/Artifacts.toml`

    Deleted ~/.julia/packages/BenchmarkTools/1cAj: 146.302 KiB
    Deleted ~/.julia/packages/Cassette/BXVB: 795.557 KiB
   ...
   Deleted `~/.julia/artifacts/e44cdf2579a92ad5cbacd1cddb7414c8b9d2e24e` (152.253 KiB)
   Deleted `~/.julia/artifacts/f2df5266567842bbb8a06acca56bcabf813cd73f` (21.536 MiB)

   Deleted 36 package installations (113.205 MiB)
   Deleted 15 artifact installations (20.759 GiB)

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

Автономный режим

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

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

Клиент/сервер Pkg

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

  1. Обновление реестров.

  2. Скачивание исходного кода пакета.

  3. Если он недоступен, скачивание артефактов, необходимых пакету.

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

  1. если функция задана, клиент Pkg сначала попытается скачать данные с сервера Pkg,

  2. в случае неудачи продолжается скачивание из исходных источников (например, с сайта GitHub).

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

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

# вручную зададим какой-нибудь сервер pkg
julia> ENV["JULIA_PKG_SERVER"] = "pkg.julialang.org"
"pkg.julialang.org"

# отменим установку, чтобы всегда скачивать данные из первоисточников
julia> ENV["JULIA_PKG_SERVER"] = ""
""

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

  • пакеты/регистры, полученные с помощью git

    • ]add https://github.com/JuliaLang/Example.jl.git

    • ]add Example#v0.5.3 (обратите внимание, что это отличается от ]add Example@0.5.3)

    • ]registry add https://github.com/JuliaRegistries/General.git, включая реестры, установленные в Julia версии, предшествующей 1.4.

  • артефакты без информации о скачивании

Если вы установили новый реестр с помощью сервера Pkg, старые версии Julia не смогут обновить реестр, потому что Julia версии, предшествующей 1.4, не знает, как получить новые данные. Следовательно, пользователям, которые часто переключаются между несколькими версиями Julia, рекомендуется по-прежнему использовать реестры, управляемые git.

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