Вот, комплексный пример как это можно заюзать в тестах:

from cykooz.testing import D, L, R, ANY

assert result == D({
    '_links': D({
        'self': {
            'href': R(r'^http://localhost/.+')
        },
        'content': {'href': ANY},
    }),
    'description': 'My Photo',
    'geo': {
        'latitude': 5.0006,
        'longitude': 3.0004,
        'addresses_i18n': L([
            D({'lang': 'RU', 'address': ANY}),
        ]),
    },
})

Кирилл @cykooz , хочу твоё мнение спросить :)
идея у меня такая.

где-то крутится api, описаное во заветам OpenAPI то есть есть схема.

есть генератор питоньих классов на основе схемы.

генератор генерит полноценное питонье яйцо.

я хочу каким-то образом это нагенерённое яйцо положить в билдауте рядом с моим яйцом.

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

[buildout]
develop =

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

я надеюсь, что я понятно описал, как можно описанное сделать красивей/правильней?

Как понял у тебя всё таки не яйцо генерится, а просто src дистриб, т.к. яйцо (которое egg) это уже zip-архив скомпилятый

Т.е. ты не хочешь сгенереный код хранить в GIT-е?

его бессмысленно генерить в гите, это всё будет частью тестов

а в тестах надо бы все актуальное генерить прямо по месту

В теории ты можешь попробовать создать фейковый пакет, там куда будет генерится код. Самый минимум: setup.py и может какой-то пакет с пустым __init__.py.
Хотя возможно билдауту на начальном этапе пофиг на всё кроме setup.py до тех пор пока он не будет его ставить в других секциях

угу, буду сейчас пробовать как оно подружит.
да, это не яйцо, не архив то есть.
а папка, содержащая setup.py и остальные потроха присущие яйцу

Проверил - билдаут с самого начал запускает
setup.py develop
во всех папках из списка develop =
Поэтому надо какой-то минимальный валидный setup.py

Есть мысль что можно попробовать самому заэмулировать это действо после того как сгенерится пакет. Но только при условии что билдаут всё время смотрит на папку develop-eggs, когда генерит скрипты, а не внутри себя помнит пути к девелоп пакетам.

А если генератор выдаёт всё время одинаковый setup.py, то вполне норм будет если покласть этот setup.py в репу.

мне какая-то такая же мысль пришла в голову, билдауту достаточно наличий setup.py чтоб отработать корректно, ему всё равно что ничего кроме setup.py больше нет

ещё была мысль сделать два конфига билдаута, одним генерить, а второй, как второй шаг, запускать только чтоб обновить пути.
но как-то это некрасиво

Можно конечно второй билдаут запускать как part внутри первого (который сначала сгенерит код) 😊

ой это ещё хуже чем пустой пакет... пустой пакет хотя бы немного очевидный, и глазу заметный сходу.
ну мне так кажется

Есть какие то серьезные минусы ставить psycopg2-binary вместо psycopg2 который билдится при установке?

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

А если что, то из исходников конечно надёжнее.

В плане?