Это никто вручную и не делает при каждом запуске. Переменные окружения вроде PYTHONPATH задаются ОДИН раз либо в конфигурации проекта/конфигурации запуска в IDE, либо на уровне среды исполнения (ОС/контейнер) для прода.
А вот уродовать КАЖДЫЙ путь импорта в проекте префиксом src просто из-за того, что разработчик не умеет пользоваться переменными окружения - это, повторюсь, костыль.
Если у вас монолит с бэком и фронтом, разделённый на директории backend и frontend, то тогда ваши пути импорта превратятся ещё и в "from backend.src.module import something", что вообще полный ужас. А при нормальном использовании PYTHONPATH всё будет выглядеть так: "from module import something".
Ну и в конце концов, загляните на гитхаб и посчитайте, в каком количестве более-менее серьёзных проектов вы найдёте свой подход, и в каком - корректный. Хорошо, если в первой категории наберётся хотя бы 1 из 10, но это навряд ли.
Добавлять переменную окружения PYTHONPATH=src при запуске.
Заменить все импорты на абсолютные относительно директории src.
Первый вариант — костыль. Второй — выглядит куда лучше.
Как раз костыль - это ваше решение. PYTHONPATH для того и существует, чтобы интерпретатор знал, откуда отсчитывать пути для импорта.
Более того, если вы попробуете в любом запущенном приложении на Python вывести значение этой переменной окружения, то вас ждёт большой сюрприз, потому что ВНЕЗАПНО в ней уже окажутся прописаны разные файловые пути, по которым интерпретатор резолвит импорты, даже если вы не задавали значение переменной вручную.
Без упоминания о том, сколько памяти жрёт гитлаб со своими раннерами, статья бессмысленна. Человек начнёт поднимать гитлаб на своём VPS с 2 ГБ оперативки, и после выполнения всех действий обнаружит, что оно не заводится.
Такие статьи - лучшая антиреклама курсов Слёрма. Какой-то обрывочный хаос с постоянным перепрыгиванием с темы на тему. И даже отступы в коде не проставлены. Это максимально пофигистичное отношение к качеству.
Ну так это особая ситуация, когда есть чёткое послание от автора: "Так делать не нужно, оно не сработает".
В исходном комментарии речь шла про другое: "не удаляйте старый код, а закомментируйте его и пусть лежит, вдруг когда-нибудь понадобится". Такой подход превращает код в свалку.
Ах вот вы какие, любители оставлять горы закомментированного мусора в коде! Что ж, я всё думал, что это из-за лени и пофигизма, а оказывается, тут прямо искренняя уверенность в том, что это правильно и хорошо :)
К сожалению, так и не увидел ответа на вопрос "причём тут надёжность". Вы как будто на ходу поняли, что надёжность здесь действительно не при чём и решили переключиться на скорость)
Но и здесь тоже большой вопрос. У вас база хранится в вольюме. Это же не write layer контейнера, там оверхед околонулевой. В каких юзкейсах вы столкнулись с хоть сколько-нибудь заметной просадкой производительности?
Простите мою дотошность, но проблема выглядит высосанной из пальца. В докере можно вычисления на гпу запускать, и пропускной способности будет хватать, а тут внезапно база данных на 1.5 тб стала бутылочным горлышком) Очень странно это звучит.
"База данных в Docker - ненадёжный способ хранения информации". В чём конкретно заключается ненадёжность и почему всё вдруг стало надёжно, как только база стала работать на хосте, а не в контейнере?
То есть суть проделанных вами действий понятна. Но зачем они были проделаны? В чём преимущество перед базой, лежащей в контейнере? В экономии 20 мб оперативной памяти? :)
Вы подменяете понятия. Запланированные групповые обсуждения - это одно. А статья вообще о другом: она о частом переключении контекста из-за мусорных отвлекающих сообщений.
И кстати, в статье показано, что запланированное отвлечение не даёт такого негативного эффекта. Там вообще пол-статьи об этом. Так что складывается чёткое ощущение, что вы её либо не прочитали, либо не поняли, но сразу побежали спорить.
То есть вы уже давно не работаете на той позиции, на которой возникают описанные проблемы, следовательно, физически не можете столкнуться с этими проблемами, но при этом утверждаете, что этих проблем нет, они надуманы, а предлагаемые решения - неправильные? :)
Всё выглядит максимально логично. Экспертное мнение от практиков, так сказать.
И как, вам часто присылают сообщения в Slack, которые содержат решение проблемы, над которой вы прямо сейчас работаете? :) Не комментарий в issue или такстрекере, не пуллреквест, а короткое сообщение в мессенджере, серьёзно?
Если вас тегают в мессенджере, то это почти всегда либо менеджер, которому нужно обязательно убедиться, что вы отвлеклись от работы прямо сейчас и прочитали это архиважное сверхсрочное сообщение от него, либо коллега, который хочет решить с вашей помощью свою проблему, а не вашу.
Так что ситуация, с помощью которой вы пытаетесь оправдать отвлекающие сообщения, выглядит полностью высосанной из пальца. Сложно представить, даже теоретически, чтобы кто-то в мессенджере стучался, чтобы сообщить решение моей рабочей задачи.
Вполне очевидным образом - задерживая крупные частицы слюны и прочие биологические жидкости, которые и формируют аэрозоль, переносящий вирус от заражённого к другим людям.
Вирусы не распространяются путём телепортации. Также у нет крыльев, реактивных двигателей и прочих приспособлений, с помощью которых можно самостоятельно добраться из точки А в точку Б.
И вот как только вы захотите что-то посерьёзнее, чем "канбан на локалхосте с JSON-хранилищем", то быстро обнаружите, что LLM чудесным образом перестаёт справляться с задачей.
Все языковые модели вызывают искреннее восхищение у тех, кто с программированием знаком лишь поверхностно. Новичкам кажется, что раз LLM смогла сделать шаблонный ABC-проект, то она так же легко справится и с созданием полноценного приложения.
Вот только она не справляется. Ни Deepseek, ни OpenAI до сих пор не дошли даже до того уровня, чтобы хотя бы корректно разделить чётко описанную логику по слоям DDD. Я уже не говорю о том, чтобы с нуля написать эту логику и не превратить её в лапшу из непонятно как переплетённых друг с другом классов.
Для использования LLM вовсе необязательно "подключаться к левым апишкам". Существует огромное количество LLM, которые можно поднять локально на своём железе, да ещё и дообучать на нужных данных.
Та же самая мысль возникла. Классификация некорректна, так как смешивает в кучу всё подряд. Например: "Кофе бывает горячий, а бывает с молоком". Вот только чаще всего кофе одновременно и горячий, и с молоком.
Автор молодец, что хотя бы попыталась разобраться, но перед публикацией статьи всё-таки стоит разобраться поглубже.
Это никто вручную и не делает при каждом запуске. Переменные окружения вроде PYTHONPATH задаются ОДИН раз либо в конфигурации проекта/конфигурации запуска в IDE, либо на уровне среды исполнения (ОС/контейнер) для прода.
А вот уродовать КАЖДЫЙ путь импорта в проекте префиксом src просто из-за того, что разработчик не умеет пользоваться переменными окружения - это, повторюсь, костыль.
Если у вас монолит с бэком и фронтом, разделённый на директории backend и frontend, то тогда ваши пути импорта превратятся ещё и в "from backend.src.module import something", что вообще полный ужас. А при нормальном использовании PYTHONPATH всё будет выглядеть так: "from module import something".
Ну и в конце концов, загляните на гитхаб и посчитайте, в каком количестве более-менее серьёзных проектов вы найдёте свой подход, и в каком - корректный. Хорошо, если в первой категории наберётся хотя бы 1 из 10, но это навряд ли.
Как раз костыль - это ваше решение. PYTHONPATH для того и существует, чтобы интерпретатор знал, откуда отсчитывать пути для импорта.
Более того, если вы попробуете в любом запущенном приложении на Python вывести значение этой переменной окружения, то вас ждёт большой сюрприз, потому что ВНЕЗАПНО в ней уже окажутся прописаны разные файловые пути, по которым интерпретатор резолвит импорты, даже если вы не задавали значение переменной вручную.
Так в вашей цитате абсолютно чётко и недвусмысленно сказано: доступ к серверу должен быть только у тех, кто купил Minecraft.
Без упоминания о том, сколько памяти жрёт гитлаб со своими раннерами, статья бессмысленна. Человек начнёт поднимать гитлаб на своём VPS с 2 ГБ оперативки, и после выполнения всех действий обнаружит, что оно не заводится.
Правильно говорить "вырубавывания" :)
Такие статьи - лучшая антиреклама курсов Слёрма. Какой-то обрывочный хаос с постоянным перепрыгиванием с темы на тему. И даже отступы в коде не проставлены. Это максимально пофигистичное отношение к качеству.
Не нужно лазить по веткам. Всё современные IDE дают возможность в пару кликов увидеть историю изменений конкретного файла в удобном виде.
Ну так это особая ситуация, когда есть чёткое послание от автора: "Так делать не нужно, оно не сработает".
В исходном комментарии речь шла про другое: "не удаляйте старый код, а закомментируйте его и пусть лежит, вдруг когда-нибудь понадобится". Такой подход превращает код в свалку.
Ах вот вы какие, любители оставлять горы закомментированного мусора в коде! Что ж, я всё думал, что это из-за лени и пофигизма, а оказывается, тут прямо искренняя уверенность в том, что это правильно и хорошо :)
К сожалению, так и не увидел ответа на вопрос "причём тут надёжность". Вы как будто на ходу поняли, что надёжность здесь действительно не при чём и решили переключиться на скорость)
Но и здесь тоже большой вопрос. У вас база хранится в вольюме. Это же не write layer контейнера, там оверхед околонулевой. В каких юзкейсах вы столкнулись с хоть сколько-нибудь заметной просадкой производительности?
Простите мою дотошность, но проблема выглядит высосанной из пальца. В докере можно вычисления на гпу запускать, и пропускной способности будет хватать, а тут внезапно база данных на 1.5 тб стала бутылочным горлышком) Очень странно это звучит.
Непонятно, ради чего всё это затевалось.
"База данных в Docker - ненадёжный способ хранения информации". В чём конкретно заключается ненадёжность и почему всё вдруг стало надёжно, как только база стала работать на хосте, а не в контейнере?
То есть суть проделанных вами действий понятна. Но зачем они были проделаны? В чём преимущество перед базой, лежащей в контейнере? В экономии 20 мб оперативной памяти? :)
Вы подменяете понятия. Запланированные групповые обсуждения - это одно. А статья вообще о другом: она о частом переключении контекста из-за мусорных отвлекающих сообщений.
И кстати, в статье показано, что запланированное отвлечение не даёт такого негативного эффекта. Там вообще пол-статьи об этом. Так что складывается чёткое ощущение, что вы её либо не прочитали, либо не поняли, но сразу побежали спорить.
То есть вы уже давно не работаете на той позиции, на которой возникают описанные проблемы, следовательно, физически не можете столкнуться с этими проблемами, но при этом утверждаете, что этих проблем нет, они надуманы, а предлагаемые решения - неправильные? :)
Всё выглядит максимально логично. Экспертное мнение от практиков, так сказать.
И как, вам часто присылают сообщения в Slack, которые содержат решение проблемы, над которой вы прямо сейчас работаете? :) Не комментарий в issue или такстрекере, не пуллреквест, а короткое сообщение в мессенджере, серьёзно?
Если вас тегают в мессенджере, то это почти всегда либо менеджер, которому нужно обязательно убедиться, что вы отвлеклись от работы прямо сейчас и прочитали это архиважное сверхсрочное сообщение от него, либо коллега, который хочет решить с вашей помощью свою проблему, а не вашу.
Так что ситуация, с помощью которой вы пытаетесь оправдать отвлекающие сообщения, выглядит полностью высосанной из пальца. Сложно представить, даже теоретически, чтобы кто-то в мессенджере стучался, чтобы сообщить решение моей рабочей задачи.
Devoxx Genie смотрели?
Вполне очевидным образом - задерживая крупные частицы слюны и прочие биологические жидкости, которые и формируют аэрозоль, переносящий вирус от заражённого к другим людям.
Вирусы не распространяются путём телепортации. Также у нет крыльев, реактивных двигателей и прочих приспособлений, с помощью которых можно самостоятельно добраться из точки А в точку Б.
А больше 5 - это 6? :)
И вот как только вы захотите что-то посерьёзнее, чем "канбан на локалхосте с JSON-хранилищем", то быстро обнаружите, что LLM чудесным образом перестаёт справляться с задачей.
Все языковые модели вызывают искреннее восхищение у тех, кто с программированием знаком лишь поверхностно. Новичкам кажется, что раз LLM смогла сделать шаблонный ABC-проект, то она так же легко справится и с созданием полноценного приложения.
Вот только она не справляется. Ни Deepseek, ни OpenAI до сих пор не дошли даже до того уровня, чтобы хотя бы корректно разделить чётко описанную логику по слоям DDD. Я уже не говорю о том, чтобы с нуля написать эту логику и не превратить её в лапшу из непонятно как переплетённых друг с другом классов.
Для использования LLM вовсе необязательно "подключаться к левым апишкам". Существует огромное количество LLM, которые можно поднять локально на своём железе, да ещё и дообучать на нужных данных.
Та же самая мысль возникла. Классификация некорректна, так как смешивает в кучу всё подряд. Например: "Кофе бывает горячий, а бывает с молоком". Вот только чаще всего кофе одновременно и горячий, и с молоком.
Автор молодец, что хотя бы попыталась разобраться, но перед публикацией статьи всё-таки стоит разобраться поглубже.