То есть некий супер-pip при доставке должен пройтись по проекту и поредактировать код? А в вызовы importlib, наверное, чего-нибудь добавить эвристически, или посендбоксить их?
Автор пакета или автор кода? Это разные роли. Автор пакета может вообще не знать Python, он может быть девопсом, например, и решать пакетированием чисто задачи доставки кода на стейдж/прод. А import должен писать джун, у которого вообще нет полномочий, чтобы решать, какую версию пакета использует проект.
Параметризовать import − это плохое решение, оно смешивает разные уровни. Импорт пакета − это код, а версия пакета − это инфраструктура. Когда, чтобы поменять что-то в инфраструктуре, приходится лезть в код − это называется «прибили гвоздями».
Иначе говоря, ждём появления в Python новой системы управления зависимостями, альтернативной pip/virtualenv/pyenv? Ну, ок тогда, пусть расцветают сто цветов.
Мне кажется, вы не очень представляете, что сравниваете. Если virtualenv − костыль, то только по сравнению с системами, стоящими на соответствующем уровне абстракции по отношению к CPython и пользовательскому коду. LXC, например. Это было бы понятно: Docker стартовал только в 2013, а virtualenv − в 2007, когда дешёвого способа создать среду исполнения ещё не было. Вы же сравниваете одну фичу интерпретатора языка со сложным компонентом, управляющим средой, в которой этот интерпретатор запускается.
Если существующие способы работы с зависимостями в Python слишком сложны (в чём я вообще-то сомневаюсь, но готов допустить), то как добавление ещё одного способа сделает жизнь проще?
Очень странный PEP. Выглядит как ползучий фичеризм и неосиляторство. В случаях, описанных в мотвационной части, пользователю либо достаточно pip install --user, либо всё равно придётся учить virtualenv. Если же хочется чего-то странного, то можно и поиграть с sys.path, как предлагает ОП. Зачем нужен ещё один глобальный механизм, непонятно.
Прошу прощения, что высказался не очень понятно. Разделять базу данных между несколькими приложениями − это всегда плохая идея. Попробую показать, почему.
Технически неоправданные зависимости. Если мы изменяем процедуру логина в одном приложении, нам наверняка нужно дорабатывать аналогичный кусок кода в другом приложении. Если мы апгрейдим СУБД для одного приложения, нам нужно убедиться, что это будет работать в другом приложении. И т. д.
Параллельный доступ. Рано или поздно вы наткнётесь на проблемы с хронологией процессов в обоих приложениях.
Производительность. Чем больше общих ресурсов, тем больше вероятность, что один из них станет бутылочным горлышком.
Возможность апгрейда. Рано или поздно вам станет мало read-only-доступа: появится необходимость синхронизировать данные в профилях пользователей, например.
Что же делать вместо общего доступа к БД? Воспользоваться API для доступа к данным. Есть несколько плагинов для Joomla, которые обеспечивают REST-сервисы. Если не все, то какие-то из них наверняка имеют возможность авторизовать клиента (в нашем случае, Django-приложение).
В крайнем случае, если доработка Joomla совсем никак невозможна, то лучше авторизовывать Django-юзера на лету через джумловскую форму логина (тоже какой-никакой интерфейс).
Это всё очень очевидные архитектурные вопросы, которые давно разжёваны. Вот пару источников, чтобы не быть голословным:
Мне кажется, давать доступ одному приложению к базе данных другого (работающего) приложения − это плохая идея. Я бы в вашей ситуации авторизовал Django-пользователя в Joomla HTTP-запросом, при помощи requests, например.
Как это вы здорово додумали за меня мою точку зрения.
То есть когда вашу технологию сравнивают с предшествущими, то вы автоматически становитесь за прогресс, значит, ваши оппоненты − ретрограды и неолуддиты. А когда с более новыми, то вы − за надёжность и проверку временем, а ваши оппоненты − безответственные хипстеры? Первосортная демагогия.
Вы уже 50 лет как обещаете ритейлу, что электронная наличность позволит ему сэкономить деньги на инкассации, но по-прежнему эквайринг обходится ритейлу дороже, чем инкассация. А может, пора отказаться от самой концепции платёжных карт как от провальной?
Не забудьте, что процессоры под 771 сокет (Xeon) отлично работают на материнских платах с 775 с небольшой модификацией, даже функции типа VT-X можно использовать. И стоят они на вторичном рынке дешевле Core 2 Quad. Их даже продают на али или ибее с накладкой для 775 сокета.
А нам не надо осознания, мы не строим свои дистрибутивы и не разрабатываем systemd. Нам надо именно что типовую таску − запустить свой процесс и перезапустить его, если упал.
Направление роста стека не всегда определяется архитектурой процессора. У PDP-11, например, стек мог расти в любую сторону, а push и pop были макросами. Что касается вызова подпрограмм, у ARM нет инструкций call и ret, есть только регистр связи − условная верхушка стека вызовов.
Основной посыл статьи понятен и даже банален: не используй для хранения данных незаполненную часть стека, потому что она может быть перезаписана в любой момент (в результате обработки прерывания, например). Но вот про «красную зону» я не знал. Хотя, как я понимаю, использование «красной зоны» на практике − довольно грязный хак, даже когда это безопасно.
importдолжен писать джун, у которого вообще нет полномочий, чтобы решать, какую версию пакета использует проект.import− это плохое решение, оно смешивает разные уровни. Импорт пакета − это код, а версия пакета − это инфраструктура. Когда, чтобы поменять что-то в инфраструктуре, приходится лезть в код − это называется «прибили гвоздями».Мне кажется, вы не очень представляете, что сравниваете. Если virtualenv − костыль, то только по сравнению с системами, стоящими на соответствующем уровне абстракции по отношению к CPython и пользовательскому коду. LXC, например. Это было бы понятно: Docker стартовал только в 2013, а virtualenv − в 2007, когда дешёвого способа создать среду исполнения ещё не было. Вы же сравниваете одну фичу интерпретатора языка со сложным компонентом, управляющим средой, в которой этот интерпретатор запускается.
pip install --user, либо всё равно придётся учитьvirtualenv. Если же хочется чего-то странного, то можно и поиграть сsys.path, как предлагает ОП. Зачем нужен ещё один глобальный механизм, непонятно.Какого года?
Что же делать вместо общего доступа к БД? Воспользоваться API для доступа к данным. Есть несколько плагинов для Joomla, которые обеспечивают REST-сервисы. Если не все, то какие-то из них наверняка имеют возможность авторизовать клиента (в нашем случае, Django-приложение).
В крайнем случае, если доработка Joomla совсем никак невозможна, то лучше авторизовывать Django-юзера на лету через джумловскую форму логина (тоже какой-никакой интерфейс).
Это всё очень очевидные архитектурные вопросы, которые давно разжёваны. Вот пару источников, чтобы не быть голословным:
www.ben-morris.com/a-shared-database-is-still-an-anti-pattern-no-matter-what-the-justification
stackoverflow.com/q/3479297/10424832
softwareengineering.stackexchange.com/q/105786
requests, например.Скажите это тем, у кого вклады дважды съедала инфляция. А также тем, у кого их сейчас банки арестовывают за «подозрительную транзакцию».
То есть когда вашу технологию сравнивают с предшествущими, то вы автоматически становитесь за прогресс, значит, ваши оппоненты − ретрограды и неолуддиты. А когда с более новыми, то вы − за надёжность и проверку временем, а ваши оппоненты − безответственные хипстеры? Первосортная демагогия.
pushиpopбыли макросами. Что касается вызова подпрограмм, у ARM нет инструкцийcallиret, есть только регистр связи − условная верхушка стека вызовов.Основной посыл статьи понятен и даже банален: не используй для хранения данных незаполненную часть стека, потому что она может быть перезаписана в любой момент (в результате обработки прерывания, например). Но вот про «красную зону» я не знал. Хотя, как я понимаю, использование «красной зоны» на практике − довольно грязный хак, даже когда это безопасно.