Как стать автором
Обновить

Комментарии 39

А вы не сталкивались с крайне медленной работой файловой подсистемы? Мы пользуем django pipeline и страницы грузятся ну очень долго с ним. Я попробовал подключить каталог через SMB, получил 5х ускорение, но загрузка страниц по 10 секунд это тоже не очень приятно.
Использую NFS под линукс и помогло ускорить вот эта статья.
Я пробовал работать таким образом — когда PyCharm начинает делать индексацию, то это очень затягивается. Очень напрягает когда надо несколько раз переключаться между разными ветками.
А если sources хранить локально, толкать их в Git и потом забирать (возможно через fabric/git hooks автоматически) в vagrant боксе?
Тогда обновление будет проходить только с коммитом, мне хотелось бы чаще.

Ниже предложили вариант со скриптом который смотрит за модификацией файлов и делает rsync. Я думаю это будет самый быстрый вариант.

По моему в каких то ИДЕ даже видел настройку заливать сразу файлы на sftp после сохранения. Можно и без доп скрипта значит.

Но я в итоге держу код на хосте, монтирую его в виртуалке вагрантом, и скорость вроде устраивает.
Вспомнил один нюанс — мы используем virtualenvwrapper, и поэтому на шаре только код проекта, а все пакеты через pip ставятся во внутреннюю память виртуалки. Мне кажется это дает приличный прирост в скорости.
НЛО прилетело и опубликовало эту надпись здесь
тогда тормоза будут на стороне IDEA
Не уверен на счет Windows, но в Линуксе это работает почти так же как с локальными дисками (синхронизация NFS/SSHFS). Несколько лет по такой схеме работаю с PhpStorm. При создании нового проекта (несколько тысяч файлов) первоначальная индексация может занимать несколько секунд, но потом работает почти мгновенно.

Лучше пусть страница вместо 0.1с будет секунду выполняться
Чем это лучше?
Проблема проявляется только при использовании django-pipeline. Оно внутри делает manage.py collectstatic, который проверяет (или копирует) много сотен статических файлов. С другой библиотекой (django-compressor) всё работает шустро как на локалке, но заказчику хотелось каких-то плюшек из django-pipeline (уже не помню чем конкретно аргументировали).

Что касается нашего проекта, то пока оставил как есть, ибо сейчас пилю только бекенд, а остальные разработчики запускают его вне виртуальных машин. Попробую потом посмотреть настройки vagrant, и, если оно может цеплять rsa ключ системы, имя пользователя и прочие — попробую перенести исходники вовнутрь.

К слову, сейчас PyCharm индексирует virtualenv через виртуалку и особых неудобств в работе нет (кроме, как выше заметили, первого запуска).
Vagrant не только для разработки под windows удобен, он по сути всего лишь автоматизирует и упрощает процесс.
А еще Vagrant создает среду, независимую операционки «носителя». У нас в команде есть и маки, линуксы, но проблемы с окружением в вагранте решаются везде одинаково. Это чертовски удобно.
Я конечно не спец по винде, но для линукса есть возможность пробрасывать папку из гостя в хост машину. Может и для винды такое есть?
Есть, но работает крайне медленно и в линуксе.
Не думаю, что скорость критична гонять py файлы туда-сюда.
Скажу так, что я сталкивался, что как раз через sharedfolders, как вы указали ниже, проект ужасно лагает. Да и не только там py там и статика и многое другое может быть. Можете набрать в гугле запрос: virtualbox sharedfolders slow, что проблемой страдают многие.
У меня хост — Линукс, ВМ — тоже Линукс (KVM). Редактирую файлы на гостевой. Для синхронизации файлов я использую шелл-скрипт, использующий inotify-tools, который при каждом изменении файла на гостевой машине запускает rsync по ssh, работает мгновенно. Для Windows есть наверняка какие-то вотчеры, которые могут по изменению файлов какой-то код запускать, BAT-файлы какие-нибудь можно написать для автоматизации.

До того, когда перешел полностью на Линукс и консольный Vim в разработке, использовал MacOS и PyCharm, в PyCharm были настройки что-то типа Creating a Remote Server Configuration, Customizing Upload/Download, там можно было по FTP, SFTP конфигурировать синхронизацию. Работало, насколько я помню, быстро. Был Suse в VMWare Player/Workstation — точно так же, через PyCharm люди, работавшие в Windows, синхронизацию настраивали. Еще наш техдир в VMWare виртуальный HDD не разбивал на несколько маленьких файлов, а использовал один большой, говорил, что так быстрее.

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

Не знаю, насколько это может пригодится в Vagrant, я так понимаю, у них там много своих скриптов для удобства. Возможно у них самих есть какие-то готовые решения.
DataArt, а у вас идет разработка под windows? Почему? Видел ваши вакансии, интересно.
У нас под всем и под все практически, на самом деле. Разные предпочтения, разные проекты.
Не очень понял статью. Почему нельзя просто полноценную виртуалку с любимым линуксом поднять, поставить на неё всё что нужно, включая PyCharm, развернуть на весь экран и дальше работать без всяких извращений? Я может задачу вашу не понял — зачем PyCharm включать на одной машине, а Python — на другой?
Потому что PyCharm в виртуалке это и есть извращение не?) Виртуалка нужна, чтобы поднять изолированное окружение, с необходимым дистрибутивом, пакетами, а не среду разработки, иксы на сервере в большинтсве случаев не к чему, а если 5 проектов, в каждом по пючарму? А если один, но надо проверить в 5 сборках…
Потому что PyCharm в виртуалке это и есть извращение не?)

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

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

С этой частью утверждения полностью согласен: виртуалки очень круто помогают с изоляцией.

а не среду разработки, иксы на сервере в большинтсве случаев не к чему, а если 5 проектов, в каждом по пючарму? А если один, но надо проверить в 5 сборках…

Почему плохо ставить на виртуалку среду разработки? Откуда взялся сервер, иксами которого вы недовольны? :-)

Дисклеймер: последние лет 7 активно использую виртуалки именно для девелопмента — ставлю всё что нужно для очередного проекта и работаю. При этом нет проблем сохранить на несколько месяцев виртуалку с предыдущим проектом, если вдруг понадобится помочь.
1. Это же избыточно, имхо. 2. Pycharm и его зависимости никак не относятся к проекту, а что если PyCharm потребуется вот какая-нибудь версия бибилиотеки одна, а проекту нужна другая версия. Одна из причин почему нынешний проект развернул под виртуалкой, хотя некоторые коллеги линуксоиды прям в своей системе, по той причине, что у меня ролинг релиз дистрибутив, и проекту требует совершенно иные версии пакетов(по старее) нежели среде разработки. Сложно придумать пример, но вот, например, захотели последнюю версию PyCharm, а проект работает под 14.04 убунтой, а последнему PyCharm например ява новее нужна, а в проекте завязано на версии, которая в 14.04.
Продолжу мысль, тут два варианта или обновлять яву, подключать там репозитории дополнительные, либо довольствоваться PyCharm постарее. Если первый вариант, подшаманили там, чтобы можно было работать, делаете фичи, потом выливается на 14.04 в jenkins на тестирование например и оказывается, что проект не работает, из-за того что в среде в которой производилась разработка были изменены какие то версии бибилотек и вот по ошибке заюзали фичу с более новой либы, которой нет в старой или вообще поломана совместимость между версиями.
Т.е. от сюда какая мысль у меня, здесь Удобство разработчика(вам вот удобно так) VS приближенные условия к боевым. Изоляция от того на чем пишет тот или иной разработчик, это не должно касаться проекта и его работоспособности. Под изоляцией я подразумевал не только изоляцию от других проектов и хост системы, а как раз что окружение приближенно к боевым и нет необходимости обновлять или ставить какую либо бибилиотеку из-за того что моей среде разработки это надо или смотрелке диффов например. Но это на более менее большие проекты критично.
Я даже не знаю, что должно произойти, чтобы я начал использовать Windows для работы. Ведь все эти действия имеют конечной целью сделать среду разработки *nix-like. Так зачем тратить время, чтобы сделать Windows таковой? Чтобы в танки потом поиграть, наверное.
Приходите вы на новую работу, а там корпоративный стандарт — Windows.
Полный социальный пакет и страдания?
Если в компании используется одна ОС для всех, то это уже дурной звоночек.
В частности, в них не Django, и для его установки приходится совершать некие не совсем очевидные действия.

Впервые об этом узнал из этого поста. Пару лет работаю с питоном и джангой на виндах, никогда никаких проблем не было. Все ставится из консоли почти так же как в никсы и просто работает.
Лично у меня из под винды были только проблемы с виртуальными окружениями(из под линукса обычно за 2 команды все разворачивается и настраивается), как-то не получилось настроить нормально. А так в Pycharm выбирал нужное виртуальное окружение и вполне комфортно работал.
У нас на проекте и так используется Vagrant и виртуалка для создания окружения с нужными версиями пакетов и т.д. На работе я выходит сидя под Ubuntu поднимаю виртуалку с еще одной Ubuntu и работаю в ней. Если вдруг надо поработать с ноутбука, то делаю то же самое с Windows-хоста.

При этом правда возникают проблемы с CRLF/LF и с ссылками закомиченными в репозиторий
Ну еще я бы посоветовал вместо архаичного putty использовать xshell.
В частности, в них не Django, и для его установки приходится совершать некие не совсем очевидные действия.

Это какие?

production.txt:
Django==1.8.3

Переключаемся на любой .py файл, жмем на install во всплывающем окне. Profit.

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

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

Не так много надо допилить для Джанго проекта, чтобы он работал как в винде, так и в линуксе.
Vagrant — это же всего лишь надстройка над VM: в связи с этим не понял Вашу мысль в начале статьи, что типа «VM — тяжело, а vagrant — в самый раз».
Вопрос, настроил примерно такую связку. Но есть засада — сторонние приложения Pycharm ом распознаются (пути прописаны в интерпретаторе), даже открываются по ctrl+b через pycharm_helpers.
НО их нет в дереве проекта в external libraries. Очень неудобно, даже можно сказать критично неудобно :(
Может надо где-то, что- подкрутить?
Сам себе и отвечу. :) Remote libraries заработали после того, как я указал директорию с джанго проектом в дереве «Mark Directory As» -> «Sources root». Как это связано — непонятно, но факт остается фактом.
После завершения установки создаем новое виртуальное окружение

Зачем вы создаете виртуальное окружение в виртуальном же образе Vagrant ?


Вы же не собираетесь в одном боксе несколько приложений разрабатывать?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий