Что означает: при условии, что в profiles.clj?

Question

Сейчас Luminus создает profiles.clj с таким содержанием:

{:provided {:env {;;when set the application start the nREPL server on load
                  :nrepl-port "7001"
                  :database-url "jdbc:mysql://localhost:3306/mysqlkorma_dev?user=db_user_name_here&password=db_user_password_here"}}}

Что: при условии сделать здесь? В документации среды кажется, что есть две записи: одна для разработчика и одна для теста https://github.com/weavejester/environ.

Answer 1

TL; DR: предоставленный профиль используется в файле profiles.clj в качестве альтернативы профилю dev, поскольку, если там используется dev, он будет перезаписывать весь профиль dev, указанный в project.clj.

---

Наиболее распространенное использование :provided это указать зависимости, которые должны быть доступны при создании jar, но будут предоставлены средой выполнения. Но я думаю, что здесь используется как способ предотвращения :env настроен в файле profiles.clj (который не предназначен для сохранения в вашем хранилище исходного кода), чтобы перезаписать :env настроено в project.clj.

Luminus использовал бы :dev профиль вместо :provided в profiles.clj, если бы не тот факт, что они уже положили вещи в :env запись в :dev профиль в project.clj, который будет перезаписан тем, что находится в profiles.clj.

Смотрите этот пример репо. Если вы запустите его сразу, без каких-либо изменений (с :provided в profiles.clj) вывод будет:

› lein run
Hello, world
Db config: some:db://localhost

Если вы измените :provided в :dev в profiles.clj выходные данные изменяются на:

› lein run
Hello, nil
Db config: some:db://localhost

Они не слились, но :env в profiles.clj переписал :env в profile.clj

---

РЕДАКТИРОВАТЬ: я только что узнал, что не только :env запись будет перезаписана, если :dev был использован в profiles.clj. Целиком :dev профиль будет перезаписан. Это объясняется в документации профилей:

Помните, что если профиль с одинаковым именем указан в нескольких местах, выбирается только профиль с наивысшим "приоритетом" - объединение не выполняется. "Приоритет" - от наивысшего к низшему - profiles.clj, project.clj, общедоступные профили и, наконец, общесистемные профили.

Итак, используя :provided в profiles.clj есть небольшой взлом вокруг стратегии объединения профилей leiningen.

У него есть как минимум один недостаток: если вам нужно определить :provided профиль в project.clj, чтобы указать зависимости, которые будут доступны в среде выполнения, он будет перезаписан тем, который определен в profiles.clj.

Answer 2

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

- Ссылка

Answer 3

Как сказал @nberger provided используется для указания зависимостей, которые должны быть доступны в вашем пути к классам, но будут предоставлены средой выполнения.

Один конкретный случай - это библиотеки, которые, если они включены в ваш проект, испортили бы свою подпись при создании uberjar.

Такова ситуация с BouncyCastle.

Так что ваши project.clj может выглядеть так:

:profiles {:dev {:dependencies [[org.bouncycastle/bcprov-jdk15on "1.50"]]}
           :provided {:dependencies [[org.bouncycastle/bcprov-jdk15on "1.50"]]}}

В этой ситуации вы говорите, что для разработки вы можете использовать библиотеку из репозитория maven, но во время выполнения она должна предоставляться средой.

Таким образом, исходный файл JAR, как есть, должен присутствовать в пути к классам:

java -cp bcprov-jdk15on-151.jar:your-standalone.jar clojure.main