Что еще за virtual environment?

Думаю, что это вот что: https://docs.python.org/3/tutorial/venv.html

Но сам пока не пользовался...

Oops, ссылка не совсем та :)

https://docs.python.org/3/library/venv.html

Это питонячинский virtual env, его можно просто не использовать, если поставил через пакетный менеджер или pip не используя venv, то просто остается найти каталог site-packages/torch и прописать путь к нему

build внутри каталога исходников, соответственно перейдя в каталог build, CmakeList файл верхнего уровня будет лежать в каталоге чуть выше, потому и пишем .. то есть две точки

есть пакет и команда, которая так называется, она позволяет все питонячие зависимости законтейнерить на текущий каталог для конкретного развертывания, соответственно внутри его среды (в нее заходят как в чрут) или будучи сконфигурированным извне (например ты разворачиваешься в ~/vasyans-bundle) у тебя $VIRTUAL_ENV будет прописан как надо

Если ты не используешь venv то и не обращай на это внимания - ставь в системный каталог (ну понятно с обычной оговоркой что из этого по-нормальному нужно сделать системный пакет).

Я вообще не пойму, что этому скрипту сборки не хватает

=== Status ===
  OpenCL: include /usr/include
          lib     OCL_LIB-NOTFOUND

...
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
OCL_LIB

В README написано, что

Make sure you have OpenCL headers and library. It should be `cl2.hpp` - not the old one `cl.hpp`

Вроде стоит opencl-clhpp-headers там в списке файлов есть cl2.hpp

Хотя вроде оказалось, что ocl-icd-opencl-dev не хватало.

А дальше пошли типичные пуки при сборке из исходников:

/pytorch/pytorch_dlprim/src/CLTensor.h:19:67: error: ‘PrivateUse1’ is not a member of ‘c10::DeviceType’
   19 |     constexpr c10::DeviceType OpenCLDeviceType = c10::DeviceType::PrivateUse1;


pytorch/pytorch_dlprim/src/utils.h:15:26: error: ‘class caffe2::TypeMeta’ has no member named ‘toScalarType’
   15 |         return todp(meta.toScalarType());


pytorch/pytorch_dlprim/src/pointwise_ops.cpp:72:17: error: ‘AutoDispatchBelowADInplaceOrView’ is not a member of ‘at’
   72 |             at::AutoDispatchBelowADInplaceOrView g;

Видимо какая-то либа не той версии или gcc не той версии или еще что-то. Пока сдался. Часы уходят на разгребание.

Если автор пишет

Make sure you are in the virtual environment

Я бы поостерегся делать смелые выводы насчет «можно просто не использовать», т.к. вся эта наколеночная ML шляпа часто требует конкретных версий пакетов иначе фокус не получится

Часы уходят на разгребание

Зачем ты этой мастурбацией занимаешься? У тебя в дистрибутиве есть пакет pytorch. Он собирается. Модифицируй его как тебе нужно.

venv это питоновский костыль для того чтобы сделать чето типа node_modules, без которого на самом деле там нихера не работает, потому что с зависимостями в бидоне жопа и ад

добро пожаловать в удивительный всратый мир бидона, и модулей на сишечке

Во всем этом ML-аду разве не conda используется?

Тогда вообще все плохо.

Но совет такой - не используй вообще нихрена из дистрибутива. Вообще. Ставь все мейкинсталлом.

Тоже верно. Сам бы свидетелем не раз как некий софт накрепко прибили к 1 конкретной версии питона четкой ревизии и четким версиям библиотек

Но совет такой - не используй вообще нихрена из дистрибутива. Вообще. Ставь все мейкинсталлом.

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

Мейкинсталом очень просто свой дистрибутив вообще в Форшмак превратить. Положим PyTorch тогда заставлю работать с OpenCL, но попутно что-нибудь поотваливается тогда.

Зачем ты этой мастурбацией занимаешься? У тебя в дистрибутиве есть пакет pytorch. Он собирается. Модифицируй его как тебе нужно.

А как мне нужно? Мне нужно, чтобы он мог с OpenCL работать. Теоретически это даже предусмотрено PyTorch как бы из коробки, но с оговоркой, что нужно специальное ядро под это дело. Которое похоже авторами PyTorch не было написано

Вот https://github.com/artyom-beilis/pytorch_dlprim что-то такое и написал. По его словам, там даже как раз сборка этого ядра идет с использованием установленного в пакете PyTorch из исходников, которые в /usr/lib/pytorch как-то там.

Тут похоже, что ровно наоборот, таки надо подсунуть отдельный pytorch той версии, для которой сиё разрабатывалось. Еще бы кстати понять какой, тоже неочевидно. Похоже 1.13 (в дистре 1.17), но не факт.

Мейкинсталом очень просто свой дистрибутив вообще в Форшмак превратить. Положим PyTorch тогда заставлю работать с OpenCL, но попутно что-нибудь поотваливается тогда.

Именно так, ну так это издержки профессии, когда со всем этим работаешь. Более того, отчасти именно из-за этого в свое время и придумали тот же докер.

Если приходится такое спрашивать на ЛОРе, то завести ROCm будет not enough mana. А указанная поделка вообще не понятно зачем тебе сдалась. Лучше сразу в Job писать, или купить карточку с поддержкой CUDA.

Но вообще, шансы запустить то что тебе нужно в докере - не нулевые, https://rocm.docs.amd.com/en/latest/how_to/pytorch_install/pytorch_install.html#option-1-recommended-use-docker-image-with-pytorch-pre-installed

Могли бы просто докер использовать, но нет, не хотим стандартных инструментов, хотим пожирать фекалии.

https://peps.python.org/pep-0405/

1. Лет больше чем докеру (но меньше чем lxc).
2. Работает везде где работает питон ибо не требует совсем ничего.

Никто же не называет костылями использование измененных переменных окружения PATH/LD_LIBRARY_PATH/прочих и уж такого «костыля» как LD_PRELOAD.

Лет больше чем докеру

Т.е. мало того, что костыль, так ещё и старьё.

Работает везде где работает питон

Но только с питоном. Для каждого недоязычка нужно учить свои особые приседания, ужимки и прыжки для решения проблемы. Не скучайте.

Но только с питоном. Для каждого недоязычка нужно учить свои особые приседания, ужимки и прыжки для решения проблемы. Не скучайте.

Прямо как пакетные менеджеры, системы сборки и прочее.

Прямо как пакетные менеджеры

apt работает со всеми языками. Привет.

А причем тут системный пакетный менеджер если разговор про пакетные менеджеры разных языков.

если разговор про пакетные менеджеры разных языков.

Тобишь вы свои костыли притащили, чтобы доказать, что … А что вы собственно пытаетесь доказать?

Ты простой Иван город Тверь, у тебя есть 5 проектов требующих разный набор библиотек конфликтующих на уровне API, при переключении между проектами ты хочешь тыц и чтобы IDE видела только нужные библиотеки нужных версий. Делать условное хранилище исходников библиотек на которое натравливать IDE в настройках каждого проекта для их индексирования, обновлять/добавлять/удалять библиотеки индивидуально для каждого проекта, тестировать локально без необходимости пересборки контейнера. А что будешь делать ты?

А что будешь делать ты?

cat <<EOF > Dockerfile
…
EOF

docker build -t WorksEverywhere:latest .

А причем тут сборка образа контейнера? Ты до нее еще не дошел.

В образе располагаются библиотеки и артефакты исполнителя, которые мне нужны. Конетейнер — это (знаю, тавтология) универсальный контейнер, в котором находится всё, что нужно для запуска процесса. Работает универсальным образом для всех языков и библиотек.

И как это поможет IDE для $ЯЗЫКНЕЙМ брать только нужные проекту библиотеки нужных версий для индексирования?

1. Монтируешь контейнер с файловой системой;
2. IDE указываешь префикс, в котором лежат все файлы;
3. Всё.
4. Вариант для извращенцев: IDE запускаете в том же контейнере (работает для X11).

Ты только что venv только еще контейнер прицепил.

Применяю универсальный метод вместо языкоспецифичного костыля и счастлив.

Такой универсальный что под каждый $ЯЗЫКНЕЙМ придется пилить свой костыль реализуя на коленке те же методы которые уже реализованы но с дополнительной прослойкой.

Такой универсальный что под каждый $ЯЗЫКНЕЙМ придется пилить свой костыль

Что вы имеете в виду?

Ты только что venv.

Вы пьяны или русский для вас неродной?

С venv проще.

Venv работает на всех платформах где есть питон. А докер разве на всех?

А что, кроме линукса ещё что-то осталось? Ну, ладно, есть ещё маргинальные платформы типа винды с макосью, но там докер тоже работает.

Ну так и запишем - универсальное, но не совсем).

Мне хватает, а маргиналы могут и пострадать. Им это даже полезно будет.

Посмотри версию питона. У автора питон 3.8.

Вот ты упертый. Venv просто создает нужную структуру директорий, делает симлинки и ставит переменные окружения.

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

Спасибо за описание сорта фекалий и палок, которыми достигаются ваши результаты.

в докере тоже venv используют.

Это уже совсем конченное извращение.