Size: a a a

2020 July 30

N

Nikita in PiterPy Meetup
Eugene
Почему я не удивлён. Очередной околонаучный проект, авторы которого не позаботились о нормальной стандартной установке/пакетировании официальных wheel пакетов для своего творения. Тысячи их.

У них там cmake для сборки c++ кода, а для питон-пакета даже нет setup.py. Можно было бы сделать нормальную сборку на базе scikit-build, но авторам пофиг. Постоянно с таким сталкиваюсь касательно кода от учёных.
https://github.com/rdkit/rdkit/pull/2690

@maksbotan пытался уже им продать это
источник

N

Nikita in PiterPy Meetup
Eugene
Почему я не удивлён. Очередной околонаучный проект, авторы которого не позаботились о нормальной стандартной установке/пакетировании официальных wheel пакетов для своего творения. Тысячи их.

У них там cmake для сборки c++ кода, а для питон-пакета даже нет setup.py. Можно было бы сделать нормальную сборку на базе scikit-build, но авторам пофиг. Постоянно с таким сталкиваюсь касательно кода от учёных.
А я правильно понимаю, что scikit-build позволяет собрать питонячий проект с ++ и запушить его в pypi?
источник

E

Eugene in PiterPy Meetup
Nikita
А я правильно понимаю, что scikit-build позволяет собрать питонячий проект с ++ и запушить его в pypi?
scikit-build это как раз для проектов, которые c++ based, которые собираются через cmake и с питонячими обертками. Он позволяет через setup.py описать сборку всего проекта, запустить cmake, запустить сборку python-extension пакетов и получить стандартный питон-пакет, например в wheel. Потом этот пакет можно загрузить на pypi естественно и ставить через pip как любой другой пакет.

Причем, если пакет будет ставиться из исходников, то будет дергаться вся нужная обвязка (компилятор, cmake и т.д.), а если это prebuilt wheel, то пакет будет ставиться без необходимости компилировать из исходников.

Я посмотрел пулреквест по ссылке, лучше, конечно перевести всё на scikit-build, будет гораздо лучше чем эти костыли.
источник

MK

Maxim Koltsov in PiterPy Meetup
Eugene
scikit-build это как раз для проектов, которые c++ based, которые собираются через cmake и с питонячими обертками. Он позволяет через setup.py описать сборку всего проекта, запустить cmake, запустить сборку python-extension пакетов и получить стандартный питон-пакет, например в wheel. Потом этот пакет можно загрузить на pypi естественно и ставить через pip как любой другой пакет.

Причем, если пакет будет ставиться из исходников, то будет дергаться вся нужная обвязка (компилятор, cmake и т.д.), а если это prebuilt wheel, то пакет будет ставиться без необходимости компилировать из исходников.

Я посмотрел пулреквест по ссылке, лучше, конечно перевести всё на scikit-build, будет гораздо лучше чем эти костыли.
я по-моему влип в то, что буст::питон нельзя линковать статически
источник

MK

Maxim Koltsov in PiterPy Meetup
а scikit-build сможет нужные so'шки в колесо запихнуть?
источник

MK

Maxim Koltsov in PiterPy Meetup
ПР я делал пытаясь как можно меньше изменений в существующую экосистему внести
источник

E

Eugene in PiterPy Meetup
Maxim Koltsov
а scikit-build сможет нужные so'шки в колесо запихнуть?
там всё как-то хитро было, но насколько я помню, нужные библиотеки надо было вручную пихать в колесо, в смысле описывать это дополнительно в setup.

Хотя я вот сейчас бегло посмотрел документацию и нашел такое:
cmake_process_manifest_hook: Python function consumming the list of files to be installed produced by cmake. For example, cmake_process_manifest_hook can be used to exclude static libraries from the built wheel.
источник

MK

Maxim Koltsov in PiterPy Meetup
ну так надо тащить libboost_python.so, который как бы вообще внешняя зависимость...
источник

E

Eugene in PiterPy Meetup
Maxim Koltsov
ПР я делал пытаясь как можно меньше изменений в существующую экосистему внести
Да это понятно, просто можно этим ребятам предложить переделать сборку их проекта, потому что сейчас там у них какой-то набор костылей.
источник

E

Eugene in PiterPy Meetup
Maxim Koltsov
ну так надо тащить libboost_python.so, который как бы вообще внешняя зависимость...
Ну и что, а как numpy или scipy wheel-ы не тащат что ли зависимости? Тоже тащат
источник

MK

Maxim Koltsov in PiterPy Meetup
ребята не согласятся)
источник

E

Eugene in PiterPy Meetup
Maxim Koltsov
ребята не согласятся)
Так им самим бы было проще свой проект поддерживать, на CI раскатывать и т.п. Их cmakelists подвергся бы минимальным изменениям, просто добавился бы ещё один слой с setup.py или pyproject.toml над этим
источник

АП

Алексей А́риксу Петр... in PiterPy Meetup
Eugene
Почему я не удивлён. Очередной околонаучный проект, авторы которого не позаботились о нормальной стандартной установке/пакетировании официальных wheel пакетов для своего творения. Тысячи их.

У них там cmake для сборки c++ кода, а для питон-пакета даже нет setup.py. Можно было бы сделать нормальную сборку на базе scikit-build, но авторам пофиг. Постоянно с таким сталкиваюсь касательно кода от учёных.
пакаджинг - сложно.
источник

АП

Алексей А́риксу Петр... in PiterPy Meetup
в смысле эти ребята думали не о распространении кода, а в основном чтобы он хоть как-то заработал в нужном направлении
источник

E

Eugene in PiterPy Meetup
Алексей А́риксу Петров
пакаджинг - сложно.
Так в том и "юмор", что все эти научно-технические-датасаенс библиотеки по своей сути (то, что там внутри делается) гораздо сложнее чем какой-то "пакаджинг", и людям, которые их пилят, похоже, просто не интересно этим заниматься, они просто не хотят тратить время на это. Типа, мы тут мозги ломали, делали супер-пупер state-of-the-art алгоритмы и хитрые числодробилки, а вы там сами думайте как будете всё это использовать. Скажите спасибо, что мы вообще это выложили в open source.

У этих ребят самих инфраструктура обычно из говна и палок одноразовая и всё на ручном управлении, они просто так работают. Для того, чтобы клепать статьи хватает. Правда в последнее время про кризис воспроизводимости заговорили, может хоть что-то изменится.

Хотя есть серьёзные лаборатории и университеты, у которых production ready продукт на выходе, но их по пальцам можно пересчитать.
источник

VP

Vadim Pushtaev in PiterPy Meetup
Классное объяснение: у нас тут наука, а не это ваше говно, поэтому заниматься мы этим не будем))
источник

MK

Maxim Koltsov in PiterPy Meetup
Да.
источник

VP

Vadim Pushtaev in PiterPy Meetup
Мой опыт не такой: наши датасаентисты не хотят и не умеют, но не считают, что это какое-то дерьмо. С радостью учатся и принимают помощь, чтобы было хорошо :).
источник

VP

Vadim Pushtaev in PiterPy Meetup
Потому что им не только бы статьи, но еще бы и людям показать :)
источник

E

Eugene in PiterPy Meetup
Vadim Pushtaev
Классное объяснение: у нас тут наука, а не это ваше говно, поэтому заниматься мы этим не будем))
Представляешь, я слышал вот почти что такие слова один в один :)

Говоришь: вот я взял твой код из репозитория, как мне его у себя установить/запустить, у тебя даже списка зависимостей нет в репе.

А тебе в ответ: мне не интересно этим заниматься, я учёный, а не программист.

Есть такой "зоопарк" моделей tensorflow
https://github.com/tensorflow/models
Думаешь, там есть какой-то стандартный механизм установки и инфраструктура для всех этих моделей? Ха-ха.

Пишет мне коллега не так давно:
"Пытаюсь использовать их модели, я сейчас нахожусь на этом шаге, но у меня что-то не работает:
# From tensorflow/models/research/
protoc object_detection/protos/*.proto --python_out=.
"

Я посмотрел в их readme, типа "установка": сделайте 100 шагов как в туториалах по настройке какой-нибудь фигни в linux, чтобы запустить наш код. Причем предлагают копировать какие-то файлы прямо в дерево с кодом tensorflow. 😀
источник