есть рецепты которые собирают яйца в кучу.. eggbasket или как-то так

Видел что то подобное, но не проверял что при этом прописывается в скрипте - думал это просто для удобства разработки, что бы в папке проекта видеть симлинки на все установленые зависимости

полагаю ты пробовал поставить Plone? 8)

полагаю ты пробовал поставить Plone? 8)

Ты имеешь виду установку с нуля? Ну да тут и мои проекты заставляют подождать

до сих пор помню в каком я был шоке, когда увидел размеры того что оно накачало

400мб питоновых пакетов, Карл!

ПИТОНОВЫХ

Но когда уже все пакеты есть в кеше то их "установка" практически ничего не занимает

Вопросик. Я создал свою папку templates в директории проекта. К ней прописал путь: 'DIRS': [os.path.join(BASE_DIR, 'templates/')]. Как мне собрать шаблоны админки туда же? Ибо вот такая проблема TemplateDoesNotExist at /admin/login/ Exception Location: /home/daniil/myenv/lib/python3.4/site-packages/django/template/loader.py in get_template, line 43

а почему DIRS?

или это внутри нового TEMPLATES дикта?

Разве не там прописывается путь к templates?

там раньше вроде глобальный TEMPLATE_DIRS был

TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [os.path.join(BASE_DIR, 'templates/')], 'APP_DIRS': False, 'OPTIONS': { 'context_processors': [ 'django.template.context_processors.debug', 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages', ], }, }, ]

TEMPLATE_DIRS По умолчанию: [] (Пустой список) Не рекомендуется, начиная с версии 1.8: Смотрите опцию DIRS для DjangoTemplates. Список каталогов, в которых будут искаться файлы шаблонов при вызове django.template.loaders.filesystem.Loader в указанном порядке. Заметим, что эти пути должны использовать прямые слэши, то есть быть в Unix-стиле, а не Windows.

Не рекомендуется

в итоге пип, который на каждый инсталл распаковывает зипы оказывается заметно шустрее билдаута, который просто меняет скрипт-обвязку 8\

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

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

виртуаленв не причем

Хотя это вырожденый случай ?

виртуаленв не причем

Рецепты с pip работают при налиии virtualenv

если будешь ставить изи_инсталлом с ключом -m, то будет и в виртуаленве

пипу похуй на виртуаленв

не надо путать

у него просто есть ключик -E для их поддержки, в остальном для него без разницы

Ну что то тогда мы запутали наше обсуждение - причём тут скрипт генерируемый биладутом и способ установки пакета?

Если билдат замедляет импорты из-за раздутого sys.path - то pip тут ничем не поможет

поможет

А как?

билдаут и изи инсталл по дефолту ставят каждый пакет в свой собственный каталог

пипу похуй на виртуаленв

что ты такое говоришь

билдаут генерит скрипты-врапперы изя же пихает пути в .pth файл оба эти варианта меняют sys.path на кучу элементов

пип же ставит с —externally-managed, что ставит пакеты напрямую в site-packages

в итоге в sys.path минимум элементов и импорту не приходится сканировать десятки каталогов

пип же ставит с —externally-managed, что ставит пакеты напрямую в site-packages

Т.е. в проекте создаётся папка site-packages? Или ты про системный site-packages?

что ты такое говоришь

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

каком проекте?

билдаут и изи инсталл по дефолту ставят каждый пакет в свой собственный каталог

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

афк полчаса

у пип инсталл есть ключик —egg ;)

каком проекте?

Ну вот я пилю проект по чётным числам, у него есть свои собственые зависимости. Рядом лежит дургой проект, который я пилю по нечётным числам - он сильно старый и требует другие версии пакетов. Где должен быть site-packages что бы эти два проекта не посрались?

В целом мне проблема билдаута со скриптом запуска понятно - да неплохо бы как то это оптимизировать. Но кроме как через создание "омлетов" в которых будут симлинки на все нужные скрипту пакеты, я пока не вижу решения. Только вот на винде это наверное не будет работать - там как то с симлинками туго

В целом мне проблема билдаута со скриптом запуска понятно - да неплохо бы как то это оптимизировать. Но кроме как через создание "омлетов" в которых будут симлинки на все нужные скрипту пакеты, я пока не вижу решения. Только вот на винде это наверное не будет работать - там как то с симлинками туго

билдауту как раз симлинки не нужны

билдауту как раз симлинки не нужны

Да ему не нужны, но из-за этого раздувается sys.path. Если запилить папку где будут симлинки на нужные пакеты - то можно в sys.path прописать только одну эту папку.

понял мысль. так можно, хотя проблематично для неймспейс пакаджей

В целом я как то не страдал никогда от скорости импорта - это ведь разовая операция. Так что для меня лично в этом нет какой то сложности. Но ради доклада я наверное потестирую скорость запуска в зависимости от размера sys.path ?

скорость импорта напрямую влияет на скорость взлёта. попробуй с PYTHONVERBOSE=1

судо пип поставит тебе в /usr/lib/pythonX.Y/site-packages (дист-пакаджи в дебиан-бейсед) туда, где уже стоят системные пакеты

pip install name --user

Без рут прав

Без рут прав

это к чему?

В защиту пипа

причем тут пип...

юзер инсталлы добавили в питон 2.6, и сетаптулзы умели их до пипа

Инстал пакетов на уровне юзера - это тоже слабая подмога при разработке. Как правило нужен инсталл "на уровне проекта", и вот поэтому типичный туториал начинается со слов "Ставим virtualenv..."

Инстал пакетов на уровне юзера - это тоже слабая подмога при разработке. Как правило нужен инсталл "на уровне проекта", и вот поэтому типичный туториал начинается со слов "Ставим virtualenv..."

в общем всё сводится к тому, что пакеты могут быть установлены: 1) каждый в свой каталог - что приводит к проблеме с раздутым сис.патх 2) все в общий префикс оба сценария можно получить с помощью и пипа и изи и билдаута

скорость импорта напрямую влияет на скорость взлёта. попробуй с PYTHONVERBOSE=1

Я что то не увидел в консоли что то указывающие на проблемы. Да, он показывает что на импорт например из django он лезет в папку с кешем установленых яиц. Но проблема не в этом как понимаю. Проблема должна быть в том что он должен очень долго искать эту папку перебирая все пути указаные в sys.path. Как увидеть в логах такой вот поиск - я пока не знаю.

изя и билдаут юзают первый вариант, связка пип+венв по дефолту юзает 2й вариант

@zartsoft Я сделал тестик небольшой. Есть проект на билдауте с 80 зависимостями добавляемыми в sys.path. Время работы manage.py help - 1.66 сек. С помощью спец. рецепта создал "омлет" - папку в которой с помощью симлинков и папок "нормализованы" все пакеты, т.е. они выглядят так как если бы были установлены в site-packages, при этом даже все пакеты с namespace-ами "нормализованы". В скрипте заменил 80 путей добавляемых в sys.path на один путь к этому "омлету". Скорость работы стала - 1.35 сек. Выигрыш всего 0.3 сек - это мелочи какие то, ради которых нет ни какого смысла отказываться от билдаута.

Когда прочитал 250 стр Лурца

Я сверхразум на половину :(

я тогда безмозглый

Когда прочитал 250 стр Лурца

я где-то там и бросил

нудно пипец

@zartsoft Я сделал тестик небольшой. Есть проект на билдауте с 80 зависимостями добавляемыми в sys.path. Время работы manage.py help - 1.66 сек. С помощью спец. рецепта создал "омлет" - папку в которой с помощью симлинков и папок "нормализованы" все пакеты, т.е. они выглядят так как если бы были установлены в site-packages, при этом даже все пакеты с namespace-ами "нормализованы". В скрипте заменил 80 путей добавляемых в sys.path на один путь к этому "омлету". Скорость работы стала - 1.35 сек. Выигрыш всего 0.3 сек - это мелочи какие то, ради которых нет ни какого смысла отказываться от билдаута.

чтото у меня билдаут запорол неймспейсы 8\

Хм, по запросу Лурц гугл выдаёт на первом месето ``Луртц (англ. Lurtz) — командир отряда урук-хай, посланный Саруманом атаковать Братство Кольца` И фотки этого чуда ?

Lutz != Lurtz

чтото у меня билдаут запорол неймспейсы 8\

Начиная с версии 2.0 они выпилили из него имитацию venv (зачем она если есть virtualenv), поэтому может возникнуть проблема если в системном питоне стоят какието нужные проекту зависимости. Системные пакеты имеет приоритет над тем что добавляется в sys.path. Ну а дальше всё просто - например все питонячии пакеты которые ставятся через apt-get ничего не знают про неймспейсы, и потому один zope.interface поставленый в систему ломает весь zope. намеспейс в проекте на билдауте

ERROR: S client not available

я уже понял, да

Я в этом случае просто устанавливаю zope.interface в системе используя easy_install

ну да, это позволяет его деактивировать

билдаут без -N невероятный тормоз

использую versions.cfg с пином версий всех пакетов - это вообще маст хев

у пип теперь есть -c для этого же

В билдауте есть опция которая вообще не станет ставить пакет если он не запинен

-c, —constraint <file> Constrain versions using the given constraints file. This option can be used multiple times.

+ есть опция которая в конце работы выведет все пакеты которые надо запинить в формате пригодном для copy-paste в versions.cfg

pip freeze

8)

Первую опцию юзаем в продакшен конфиге, вторую в dev-конфиге - радость и благодать

пип удобен тем что позволяет итеративно доставлять чтолибо

билдаут надо прогонять на каждом чихе

pip freeze

pip freeze делает не тоже самое - он выдаёт всё то барахло что ты успел установить в venv, а не то что нужно реально для твоего проекта

пип удобен тем что позволяет итеративно доставлять чтолибо

Ну вот блин, нашёл сложность, как будто ты каждые полчаса ставишь новые зависимости. Прогнать билдаут один разок, когда у тебя есть versions.cfg занимает считаные секунды (на моём проекте с 80 зависимостями и 10-ю секциями в конфиге билдаута - 6 сек)

с -N?

без -N

у меня одно яйцо плоны ставится 3 минуты. и это без изменений в пакетах вообще

с -N мгновенно

не могу понять кто мне неймспейс зопы распидарасил 8(

Если не ошибаюсь, то -N - отключает поиск новых версий пакетов в PyPi. У плона много зависимотей - поиск ковых версий идёт долго. Но если все версии запинены - то билдаут не будет ничего искать

плон тащит за собой 250 зависимостей

потому и поставил, как хороший бенчмарк

Ну да, потому что там было принято не делать комбайны аля джанго ?

ZCA и всё такое

всё, нашел виновника 8\

зца няшка, но это осознание приходит далеко не сразу

Думаю ты согласишься что пинить версии всех зависимомтей - это пярмо обязательно нужно. А потому билдаут проекта без versions.cfg - это сам себе злобный буратино

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

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

меня устраивает когда зависимости выполняют свои контракты 8)