Альтернативные реализации точек входа (расширений) python / setuptools на других языках / приложениях

Хотя этот вопрос связан с серверной частью python, вопрос не привязан к самому python, а скорее о механизмах расширения и о том, как регистрировать / искать плагины.

В python концепция точек входа была введена с помощью setuptools и привязана к метаданным установленных дистрибутивов Python (называемых пакетами в других системах упаковки).

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

• Foo определяет точку входа «entrypoint1» и ищет плагины, зарегистрированные под этим именем.
• Запретить регистрацию вызываемого объекта ( Bar.callable ) в точке входа «entrypoint1».
• После этого любой скрипт python может указать Bar.callable как один из зарегистрированных вызываемых объектов для «entrypoint1».

С помощью setuptools приложения регистрируют точки входа во время установки, и информация сохраняется в связанных метаданных в пакет, называемый .egginfo (который обычно содержит информацию об имени дистрибутива, его зависимостях и некоторые другие метаданные об упаковке).

У меня такое чувство, что метаданные упаковки - не подходящее место для хранения такой информации, поскольку Я не понимаю, почему эта информация привязана к упаковке.

Мне любопытно услышать о таких возможностях точек входа / расширений / плагинов на других языках, и особенно, привязана ли концепция к метаданным и упаковке или нет. Итак, вопрос…

У вас есть примеры, на которые я должен обратить внимание? Не могли бы вы объяснить, почему выбор дизайна был сделан именно так?

Можете ли вы увидеть различные способы решения этой проблемы? Вы знаете, как эта проблема уже решена в разных инструментах? Каковы недостатки и преимущества текущей реализации Python перед другими?

То, что я нашел до сих пор

Я нашел в разных проектах, способ создания и распространения «плагинов», которые особенно заботятся о том, «как мы делаем плагины».

Например, libpeas (структура подключаемого модуля gobject) определяет набор способов расширения поведения по умолчанию путем указания подключаемых модулей. Хотя это интересно, меня просто интересует его "регистрация и поиск" (и, в конечном итоге, загрузка).

Вот некоторые из моих выводов на данный момент:

Libpeas определяет свой собственный файл метаданных (* .plugin), в котором хранится информация о типе вызываемого (возможно наличие разных плагинов на разных языках). Основная информация здесь - это имя модуля для загрузки.

У Maven есть проектный документ , содержащий информацию о том, как там управлять всем. Maven управляет надстройками с их зависимостями и метаданными, поэтому кажется интересным местом, где можно посмотреть, как они реализовали вещи .

Как указано в их документации, надстройки maven используют аннотации ( @goal ) в классах, который затем используется для поиска всех плагинов, зарегистрированных с определенной @goal . Хотя этот подход возможен в статических языках, его нет в интерпретируемых языках, поскольку мы знаем только, какие все возможные классы / вызываемые объекты в определенный момент времени могут измениться.

Mercurial использует центральную конфигурацию. файл ( ~ / .hgrc ), содержащий сопоставление имени плагина и пути, по которому он может быть найден.

Еще несколько мыслей

Хотя это не ответ на этот вопрос вопрос, также интересно отметить, как реализованы точки входа в setuptools,и как они сравниваются с точки зрения производительности, с ртутными.

Когда вы запрашиваете конкретную точку входа с помощью setuptools, все метаданные считываются во время выполнения, и таким образом создается список . Это означает, что это чтение может занять некоторое время, если у вас на пути много дистрибутивов Python. Mercurial на другой стороне жестко закодирует эту информацию в один файл, что означает, что вы должны указать полный путь к вызываемому объекту, тогда зарегистрированные вызываемые объекты не «обнаруживаются», а «читаются» непосредственно из файла конфигурации . Это позволяет более детально настраивать то, что должно быть доступно, а что не должно быть, и кажется быстрее.

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

Почему точки входа в настоящее время привязаны к упаковке

Также интересно понять, почему точки входа привязаны к упаковке в инструментах настройки. Основная причина в том, что кажется полезным, что дистрибутивы python могут регистрировать часть себя как расширяющую точку входа во время установки: тогда установка означает также регистрацию точек входа: нет необходимости в дополнительном шаге регистрации.

Хотя это довольно хорошо работает в в подавляющем большинстве случаев (когда дистрибутивы python фактически устанавливаются) этого не происходит, если они не установлены или просто не упакованы. Другими словами, насколько я понимаю, вы не можете зарегистрировать точку входа во время выполнения, не имея файла .egg-info.