Спасибо за интересную статью. Кстати о тестах. А что думаете о pyVows? (Тут рассказывают как использовать в Django.) Пока это моя любимая либа для тестов.
А нет проблемы, что какие-то системные утилиты начинают использовать установленный python и не запускаются, так как не могут найти модули установлены в старый python?
У pip есть ветка, в которой добавлена поддержка wheel.
Можно и без localshop — зависит от потребностей. По началу у нас была общая папка под NFS; сборочная машина кладет, а сервер оттуда ставит. Можно использовать и для разработки в офисе, чтобы не тянуть с интернета. С nginx тоже получится, хотя часть API pip'а не будет работать (с поиском кажись). Если требуется аутентификация, то можно настроить basic_auth на nginx.
Плюсы использования localshop:
1. Самое главное — возможность загрузки пакетов: своего проекта, сторонние дописанные модули. Например, надо как-то допилить чей-то модуль, и не хочется ждать пока автор примет pull request. Добавим, например, свои инициалы в версию в файле setup.py и зальем в свой индекс. В requirements.txt своего проекта указываем нашу версию, так во время развертки избежим вытягивание из git'a и мороки с доступом к приватным проектам.
2. Аутентификация: каждому сотруднику выдать по пользователю, при нужде можно отключить без возни с htaccess файлами.
3. В фоновом режиме подгружает используемые модули — выступает как зеркало.
Вот так загружаем свой проект в индекс(загрузит .tar.gz и .whl пакеты): python setup.py sdist bdist_wheel upload -r mypypi
Если ваш проект написан только на питоне, то bdist_wheel можно исключить.
А эта команда скачает все зависимости, построит из них wheel пакеты, и загрузит их в индекс: pip wheel -v --build-option upload --build-option -r --build-option mypypi -r requirements.txt
Могу в деталях описать в отдельном посте, будет ли полезно?
Кстати они тоже говорят, что не факт что будет работать:
We recommend ActivePython users to install packages using PyPM, and only if that fails (usually it doesn't), attempt the same using pip/easy_install.
Можно пытаться комбинировать: сначала ставить из pypm, а нерабочие пакеты ставить из своего индекса. Но тут есть опасность, что нерабочий модуль обнаружится не сразу.
В имени файла есть информация о версии питона и платформе.
Можно и без localshop — зависит от потребностей. По началу у нас была общая папка под NFS; сборочная машина кладет, а сервер оттуда ставит. Можно использовать и для разработки в офисе, чтобы не тянуть с интернета. С nginx тоже получится, хотя часть API pip'а не будет работать (с поиском кажись). Если требуется аутентификация, то можно настроить basic_auth на nginx.
Плюсы использования localshop:
1. Самое главное — возможность загрузки пакетов: своего проекта, сторонние дописанные модули. Например, надо как-то допилить чей-то модуль, и не хочется ждать пока автор примет pull request. Добавим, например, свои инициалы в версию в файле setup.py и зальем в свой индекс. В requirements.txt своего проекта указываем нашу версию, так во время развертки избежим вытягивание из git'a и мороки с доступом к приватным проектам.
2. Аутентификация: каждому сотруднику выдать по пользователю, при нужде можно отключить без возни с htaccess файлами.
3. В фоновом режиме подгружает используемые модули — выступает как зеркало.
Вот так загружаем свой проект в индекс(загрузит .tar.gz и .whl пакеты):
python setup.py sdist bdist_wheel upload -r mypypiЕсли ваш проект написан только на питоне, то bdist_wheel можно исключить.
А эта команда скачает все зависимости, построит из них wheel пакеты, и загрузит их в индекс:
pip wheel -v --build-option upload --build-option -r --build-option mypypi -r requirements.txtМогу в деталях описать в отдельном посте, будет ли полезно?
Кстати они тоже говорят, что не факт что будет работать:
Можно пытаться комбинировать: сначала ставить из pypm, а нерабочие пакеты ставить из своего индекса. Но тут есть опасность, что нерабочий модуль обнаружится не сразу.
+ архив может содержать бинарные файлы для определенной платформы.
wiki.python.org/moin/PythonPackagingTerminology