Решил разобраться как все устроено и что от куда и куда. Вот до чего дошел

Вопрос остался не решенным
-Участвуют ли dev пакеты в постоянной связи? Если да, то для чего? И правильно ли вообще отображены связи?

Многие библиотеки для питона - это порты с сишных библиотек.Почти вся стандартная библиотека, numpy, scipy, shelpy, pyproj, pillow и многое другое. Разумеется, обертка над сишным кодом быстрее, чем код реализованный на питоне. Поэтому часто установка питоньей библиотеки выполняет компиляцию сишного кода. А для этого нужны хидеры сишного кода самого питона и зависимых сишных бибилотек. Что в линуксе выражается в виде dev-пакетов.

FishHook
хидер

То-есть dev пакеты исполняются один раз для компиляции psycopg для более быстрого доступа к postgresql? Я правильно понимаю?

libpython-dev - это лишь пакет с Сшными заголовками (*.h файлы) для сборки модулей написанных на С в бинарный пакеты

исполняются один раз

да

slav0nic
libpython-dev - это лишь пакет с Сшными заголовками (*.h файлы) для сборки модулей написанных на С в бинарный пакеты

В данном случае тогда сборка psycopg происходит с чем и в какой момент?

Значит простым языком можно объяснить так, что psycopg это посредник между python и postgresql. У psycopg выполняется код для связи различных версий с различными заголовками у postgresql и python. Для того, чтоб не исполнять лишний код, мы можем скомпилировать psycopg так, чтоб он работал определенно с данными версиями и работал с заголовками на прямую без использования лишнего кода и естественно без лишних затрат времени?
Или psycopg становится неотъемлемым бинарным кодом Python и как таковой более отдельно не используется?

zavx0z
и работал с заголовками

ненене, вам надо почитать про компиляцию и линковку программ Си.

FishHook

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

Продолжение следует…. Опять в ступоре(

Опытные товарищи, помогите!!! Как берет ngnix статику? Ему кто путь указывает gunicorn или Django? Интерпретатор в этом деле задействован с кем, наверное с gunicorn'ом, он ведь WSGI. Значит, что? Gunicorn делает запрос к Django через интерпретатор на динамику и статику, возвращает ответ через интерпретатор, отдает путь ngnix'у, и отдает динамику клиенту? Ngnix забирает с пути, который ему передал Gunicorn статику? Данные из базы идут в Django через интерпретатор и из Django снова через интерпретатор в gunicorn?
Похоже Gunicorn тут самый центровой конь однорогий! Видимо он спрашивает у клиента че ему надо, потом спрашивает у Django с кого что спросить и кого куда послать. А Django мозг, всезнающий. Ngnix шестерка.
Все-таки наверное динамические данные формируются из Django и Postgresql'a в нем, а ngnix'а он только постоянно куда-то посылает? Так по логике вещей должно наверно быть?

nginx это посредник между клиентом и приложением. Он вообще статику не будет сам раздавать если это явно не указать.