Должен ли я связывать библиотеки C с моим приложением Python?

Если у меня есть пакет Python, который зависит от некоторых библиотек C (например, научной библиотеки Gnu (GSL) для численных вычислений), стоит ли связывать библиотеку с моим кодом?

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

Однако возможны ли конфликты, если у пользователя уже установлена ​​​​библиотека, или есть какие-то другие причины, по которым я не должен этого делать?

Я знаю, что могу упростить задачу для пользователей, просто предоставив бинарный дистрибутив, но я хотел бы избежать необходимости поддерживать бинарные дистрибутивы для всех возможных ОС. Итак, я хотел бы придерживаться исходного дистрибутива, но для пользователя (который с гордостью владеет компилятором C) установка должна быть так же проста, как python setup.py install.


python c distutils
person oceanhug    schedule 15.01.2011    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Распространение — одна из сложных частей любого программного проекта. Java и .NET снимают часть этого бремени, определяя стандартную среду выполнения, а затем просто говоря: «Просто распространяйте все остальное». Минус конечно есть: все надо переписывать на языке, поддерживаемом рантаймом — как только вы захотите использовать нативный код, вы потеряете все преимущества.

В Python это сложнее, чем в Ruby, C, C++ и других языках, поскольку они обычно используют существующие нативные библиотеки.

Вообще говоря:

  1. Сделайте возможным получение исходного sdist, например, через pypi.python.org. Правильно установите свой install_requires (возможно, вам потребуются привязки python для GSL, а не сам GSL). Используйте стандартный макет setuptools/distribute. Это позволит любому — скажем, мейнтейнеру любого дистрибутива — взять ваше программное обеспечение и упаковать его.

  2. Кроме того, рассмотрите возможность предоставления полномасштабного устанавливаемого пакета для вашей аудитории. Вам не нужно поддерживать все дистрибутивы и операционные системы; выберите один или два, которые, по вашему мнению, будут использоваться чаще всего. Такие инструменты, как PyInstaller, позволят вам создать устанавливаемый и работающий пакет для многих операционных систем, но особенно для linux вы можете захотеть, чтобы пользователь установил собственную версию переходного deps (libgsl?) дистрибутива — вам понадобится полноценный пакет deb или rpm, чтобы удовлетворить это — опять же, не пытайтесь поддерживать какой-либо дистрибутив, ты сойдешь с ума. Поддержите то, что вы используете чаще всего, и позвольте другим пользователям помочь вам с другими потребностями в упаковке.

Также ознакомьтесь с Руководством по упаковке Python.

person Alan Franzoni    schedule 20.01.2011

arrow_upward
0
arrow_downward

У вас может быть две отдельные ветки src, одна из которых содержит библиотеки, а другая — нет. Таким образом, вы можете явно предупредить своих пользователей, если они установили библиотеки. Другим решением может быть (если позволяют лицензии библиотек) заключить их в один файл.

Я думаю, что нет уникального решения, но это идеи, которые я мог придумать до сих пор.

Удачи

person DarkThrone    schedule 15.01.2011

arrow_upward
0
arrow_downward

Вы можете использовать virtualenv, чтобы создать частную среду Python для своего приложения. Это позволяет избежать конфликтов с другими библиотеками. Лучше всего упаковывать модули и зависимости, такие как библиотеки, с помощью Distribute. Distutils — это еще одна вещь, которую стоит изучить.

person Brian Lyttle    schedule 15.01.2011