LINUX.ORG.RU

pip+cmake

 , ,


0

2

В продолжение этой темы. Потихоньку готовлю к публикации свой велосипед. В качестве системы сборки таки выбрал cmake и все завимисости тяну им же через FetchContent (кроме самого пайтона с хедерами). Встал вопрос, как теперь это правильно опакетить? Я попытался что-то изобразить с setup.py — ну он нормально вызывает cmake всё компилирует, создаёт egg, а дальше пока затык. Не совсем понимаю а куда потом это всё копировать/инсталлировать? Собственно, конечная цель что бы при наличии в системе компилятора и пайтона можно было установить простым pip3 install передав ему директорию или ссылку на гитхаб.

Таким образом, вопросы:

1. Какие пути надо прописать в cmake (или в setup.py). В моём случае скомпилированный проект представляет из себя две so-библиотеки + некоторое количество полезных python-снипплетов.

2. После старта, основной бинарник библиотеки динамически подгружает числодробильный бекенд. Мне не совсем понятно как правильно задать путь по которому искать бекенд, если он отличается от текущего $PWD. Я так понимаю, в моём случае лучше всё содержимое лучше держать в директории, обернув __init__.py. Но, тогда я так понимаю, при инициализации модуля библиотеки ей надо будет передать путь по которому она находится, или?

3. Есть ли истории успеха перехода с pybind11 на nanobind? Очень хочется всё таки дёргать только Py_LIMITED_API. Эта привязка к версии пайтона совсем не хорошо.

★★★★★

Последнее исправление: thunar (всего исправлений: 1)

Тут основной вопрос в использовании. Я знаю два сценария:

  1. самый типовой сценарий - на машине ровно один юзер такой штуки. развертывается в локальную директорию и в ней же юзается, системная установка не требуется.

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

Вывод - cmake тут нужен только в случае если приложение кроссплатформенное, а так достаточно gnu make. Если очень прямо чешется, можно добавить цели install и links-install (прописывает в систему мягкие ссылки к локальной копии - так удобнее накатывать обновления).

При локальной установке с путями вообще проблем нет, при глобальной - все ставится туда где питоньи либы лежат в виде отдельного модуля, включая .so

PS про биндинг C++ кода - гляньте таки SWIG, для наших свистелок это ИМНО оптимальное решение. Последняя версия научилась doxygen комментарии в питон засасывать;-)

PPS еще раз подчеркну - для людей которые используют такие вещи по работе нет проблемы набрать

git clone ...
cd ...
make

;-)

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

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 2)
Ответ на: комментарий от AntonI

гляньте таки SWIG

Та видел я swig, даже использовал его. Не то, у меня много пайтоновских типов в конструкторы передаётся и потом с ними много работы идёт на этапе препроцессинга. Тот же Монте-Карло настраиваю списком пайтоновских словарей, а там внутри numpy-массив может быть, и ссылка на файл из fs, и функция заданная аналитичеки. В любом случае, код уже написан и оттестирован перписывать с нуля я его точно не буду. Но вот nanobind заинтересовал, т.к. автор как раз обещает лёгкую миграцию с пайбинда.

При локальной установке с путями вообще проблем нет, при глобальной - все ставится туда где питоньи либы лежат в виде отдельного модуля, включая .so

Ну есть ещё такая штука как pip3 install -e <...> Мне это хочется что бы отделить юезрспейс код задач от кода библиотеки. Сейчас у меня просто в дирекориях с задачами накиданы символические ссылки на либу и бекенд — это нифига не эстетично, ла и не кроссплатформенно. Хочу что бы можно было нормально в локальное окружение установить и импортировать без привязки к директории кода.

нет проблемы набрать

Объясни это не погромистам или вентузятникам. Надо делать удобно.

thunar ★★★★★
() автор топика
Последнее исправление: thunar (всего исправлений: 1)
Ответ на: комментарий от thunar

у меня много пайтоновских типов в конструкторы передаётся и потом с ними много работы идёт на этапе препроцессинга

Выглядит как какое то извращение;-) Вот чем SWIG хорош - можно не парясь делать С++ структуры и потом набивать их из питона, и это вообще ничего не стоит.

У pip че то отломали при последнем обновлении, там теперь какие то окружения надо мутить. Я в этом ничего не понимаю толком, но я бы лично его трогать не стал - gnu make хватает.

Если конечно целевая аудитория кода инженеры, то еще можно как то морочится с упрощением установки. Если такие же гики, то сами разберутся, установка тут самая меньшая из проблем…

Сейчас у меня просто в дирекориях с задачами накиданы символические ссылки на либу и бекенд

У меня моя либа и пр стоит системно. Если на сервере развертываюсь, то специально есть возможность явно прописать к ней путь (либо в Makefile либо в конфиге). Это pip как то должен решать конечно.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

делать С++ структуры

Тогда б у меня уже не два а три слоя абстракции было. Это ж надо было вначале на пайтоне подготовить много чего на этапе инициализации, заслать это в либу, потом в бекенд. Ну оно привязано к API кода, так что пока я его до конца не стабилизировал то из плсюсов оказалось банально удобнее всё подготовить. В моём представлении, python — это всё таки для high level stuff и прототипирования, для middle-layer таки лучше плюсы.

thunar ★★★★★
() автор топика
Последнее исправление: thunar (всего исправлений: 4)
Ответ на: комментарий от thunar

Дык я о том и говорю же!

Вот вычислительное ядро:

class Model{
...
   double e;   ///< заряд электрона
   double m_e; ///< масса электрона
...
};

бахаем по нему SWIG-ом (для этого надо написать .i файл в пять строчек ну и Makefile) и вуаля:

from model import *
M = Model()
M.e = ...
M.m_e = ...

причем в питоне уже работает и рефлексия, и комменты C++ видны для интерфейса - вообще все. И все что есть в плюсах автоматом в питон пробрасывается.

А так надо как то в плюсах (pybind наверное поможет, но это такое) словари эти питоньи накатывать… вот уж это точно лишний уровень абстракции.

Все это уже давно пройденный и до мелочей изученный этап;-)

AntonI ★★★★★
()

Если нужно сишку и питон разом, то либо объявляй сишку как extension, либо бери что-то типа bazel которое может разом и питон и сишку

upcFrost ★★★★★
()