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

Хотя этот вопрос имеет бэкэнд 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 с другой стороны hardcode эта информация в одном файле, что означает, что вам нужно указать полный путь к вашему вызову, тогда зарегистрированные вызовы не "обнаруживаются", а "читаются" непосредственно из файла конфигурации,Это позволяет более детально настроить то, что должно быть доступно, а что не должно быть, и кажется быстрее.

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


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

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

Ответы [ 2 ]

1 голос
/ 21 октября 2013

В качестве одной из возможных идей вы можете рассмотреть концепцию OSGi , которая используется для управления системой плагинов Eclipse . Это может быть излишним для вашего конкретного случая, но определенно источником вдохновения.

0 голосов
/ 19 августа 2011

Поскольку вы начали говорить о реализации / обработке на языке программирования, возможно, стоит отметить, что недавно gcc приобрел возможности плагинов .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...