В django появилась возможность использования своей модели вместо contrib.auth.models.User

Некоторые из них уже и не поддерживаются, но вполне себе работают.

В django появилась возможность использования своей модели вместо contrib.auth.models.User

Ключевое слово — «как-то». Да, оно действительно работало, но душа перфекциониста требует избавления от уродливых костылей.

В django появилась возможность использования своей модели вместо contrib.auth.models.User

Очень даже есть. Я чуть выше написал своё имхо.

В django появилась возможность использования своей модели вместо contrib.auth.models.User

В этом весь трагизм ситуации и заключается: появился чудесный механизм, а использовать его совместно с другими батарейками не получится.

В django появилась возможность использования своей модели вместо contrib.auth.models.User

По-моему, get_profile() мало где используется ввиду своей ущербности. Да и не о нём речь, а о приложениях, в которых захардкожена ссылка на User:

from django.contrib.auth.models import User

class Blog(models.Model):
    user = models.ForeignKey(User)

А ведь есть ещё и всякие django-registartion и аналоги, где создаются объекты именно auth.User. Существенная часть приложений, возможно даже хороших, станет несовместимой.

В django появилась возможность использования своей модели вместо contrib.auth.models.User

Супермен, ты всё-таки существуешь!

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

Vanilla JS — очень мощный javascript-фреймворк

Igniter-zen-i-rails, my new PHP framework внимательно наблюдает за собратом

Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

Да, я её уже нагуглил, спасибо :-)

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

Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

Я правильно понимаю, что Makesite сперва надо на целевом сервере установить?

Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

Мне как-то спокойнее, когда проекты разрабатываются в девственно чистых окружениях, изолированных от системного. Это гарантирует, что слепок окружения (pip freeze) покажет те и только те пакеты версий, которые используются в проекте. Удобно :-)

Ради такой независимости пакетов можно и gcc потерпеть, и кучу dev-пакетов с заголовочниками. Лежат себе, каши не простят.

Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

Самое простое — разные версии какого-либо пакета. К примеру, проекту нужен именно psycopg2==2.4.1 (после этой версии что-то поменяли в механизме транзакций), а в пакете будет самый свежий, 2.4.5.

Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

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

Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

Установкой MySQL-python не Fabric занимается, а pip:

run('pip install MySQL-python')

Если в системе будут найдены требуемые h-файлы, за милую душу соберёт. А ещё ведь и easy_install есть, он, кажется, умеет и из бинарных сборок ставить.

Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

Ну это же странно: то ли пакеты платформозависимые собирать, то ли писать на хорошо известном питоне простые и понятные вещи.

Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

Скажите, а почему Вы не использовали Fabric? Всё-таки более питоничное решение

Sypex Geo — быстрое определение города по IP

Да, похоже, Вы правы. Тут явно речь идёт о Северске донецкой области, даже координаты совпадают.

Что, однако, не отменяет моего подозрения об ошибке в базе, а наоборот, усиливает.

Sypex Geo — быстрое определение города по IP

Зашёл из Томска:



Город определился почти верно, к нему претензий нет: в конце концов, такие записи почти во всех базах RIPE. Но почему на карте Украина? :-)

Упрощая жизнь c Django

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

Упрощая жизнь c Django

Решать проблему заранее, может, и не следует. А вот от канонических дыр лучше бы закрыться. Кстати, забыл спросить, а почему в том примере айдишник берётся из request.POST?

Упрощая жизнь c Django

Спасибо. Но даже если и использовать, всё равно как-то грустно, что придётся подключать django-braces для микшинов, django-annoying для get_object_or_None и django-extensions для чего-нибудь ещё.

Вот бы один метапакет, в котором это всё в одном месте было… Не совсем джанго-вэй, конечно, но его можно разбить на аппы и подключать только нужное:

INSTALLED_APPS = (
    'metapacket.views',
    'metapacket.shortcuts',
    'metapacket.decorators',
)

Вроде и красиво, и зависимостей не плодит.