Альтернативные реализации точек входа (расширений) 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 и как они сравниваются с точки зрения производительности с ртутными.

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

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

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

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

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