Конфигурация pytest тестов

Что значит «путь к пакету»?

Впрочем, просто создай virtualenv с нужными версиями пакетов и всё (requirements.txt в помощь). А задавать пути итп это, имхо, неправильно.

Ну, юзекейс вызова примерно такой:

Собрался на CI пакет вида product_1.2.3.abcdef Нужно прогнать на этом пакете тесты.

Т.е. следующий билд будет называться product.1.2.4.deadb

Я абсолютно не против сделать всё по науке, но деплоить в какое то захардкоженное место не очень бы хотелось. Особенно, учитывая, что сам продукт написан не на питоне.

Из описания пока понятно, что ты не знаешь как сконфигурировать CI, а не pytest.

Но попытаюсь угадать — передавать путь через переменную окружения?

Переменные окружения это как вариант, да и фикстуру на сессию которая читает конфиг.

Вопрос - как задумано авторами фреймворка(если задумано).

Вопрос - как задумано авторами фреймворка(если задумано).

https://docs.pytest.org/en/latest/example/simple.html#pass-different-values-t...

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

О! Спасибо. Как же я это проглядел :(

Собрался на CI пакет вида product_1.2.3.abcdef Нужно прогнать на этом пакете тесты.

Я всё ещё не понимаю в чём проблема. Создаешь virtualenv с нужными пакетами, прогоняешь в нём тесты.

Разница в том, что надо деплоить пакеты в определенное, захардкоженное место(относительно корня virtualenv например).

Но может быть - я тебя не понимаю.

Вот исходные данные. Есть пакеты развёрнутые в /opt/foo-1.2.3, /opt/foo-1.2.4 и /home/vasya/pupkin/foo. При этом, продукта минимум два(тестируется их взаимодействие): /opt/bar-1.5.1, /opt/bar-1.5.2 и /home/vasya/pupkin/work/bar.

Как используя virtualenv - протестировать все три пары пакетов не меняя сорцы тестов?

создать 3 отдельных virtualenv и переключать их.