pip+cmake

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

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

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

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

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

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

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

git clone ...
cd ...
make

;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В продолжение этой темы. Потихоньку готовлю к публикации свой велосипед. В качестве системы сборки таки выбрал cmake и все завимисости тяну им же через FetchContent (кроме самого пайтона с хедерами).

Учти только что для попадания в системные репозитории это непригодно. Либо никто этот ужас не будет пакетить, либо твой FetchContent заменят на нормальные системные зависимости от соответствующих модулей. Если пишешь это для людей, а не только для себя, сделай опцию для использования системных зависимостей.

Нет, там ему точно не место, это узкоспециализированный фреймворк. Единственный предполагаемый способ установки — это pip прямо к гит-репозиторию.