Comments 71
python3 dab_deconv_area.py -p /home/meklon/Data/sample/test/ -t 35 -e 89 -s -a
После написания setup.py ваш проект можно будет загрузить на pypi.python.org и ставить оттуда вот так:
pip install (project name)
Или можно ставить прямо из мастер (или любой другой) ветки вашего репозитория:
pip install https://api.github.com/repos/meklon/DAB_analyzer/tarball/master
Вы можете сделать standalone-сборку своей программы, например, с помощью cx_freeze.
Для Windows ещё есть неофициальные сборки wheel-пакетов: http://www.lfd.uci.edu/~gohlke/pythonlibs/
По хорошему, проект должен иметь такую структуру:
- Библиотечный пакет или модуль, который предоставляет API ко всей вычислительной части
- Приложения, утилиты, примеры (консольные и/или GUI), а также тесты, которые используют этот API
То есть разработку проекта надо вести снизу-вверх. Сначала пишется библиотека, а потом над ней утилиты и приложения.
Всем этим в консоли, конечно, пользуется скорее специально обученный биоинформатик, а не просто биолог без навыков программирования/линуксоводства. У меня один коллега вообще здорово удивился, увидев локальный BLAST. Но если вы в любом случае не собираетесь делать полноценный GUI — то тонна ключей лучше, чем что-то интерактивное на curses или, избави Господи, текстовое меню в консоли.
В голову приходит вариант импорта по номеру вектора в файле. Что-то типа ключа --vector 3, где 3 это, например, массив с вектором эозина.
matrixVectorDabHE = np.array([[0.66504073, 0.61772484, 0.41968665],
[0.4100872, 0.5751321, 0.70785],
[0.6241389, 0.53632, 0.56816506]])
Хранение напрямую в виде человекочитаемых переменных сразу Python выглядит весьма разумно. Хотя несколько неожиданно)
numpy-массивы можно писать в файлы и читать из файлов. Вот документация: http://docs.scipy.org/doc/numpy/reference/routines.io.html
Вдруг пригодится.
Python всё еще торт :) В 1997 на третьем курсе физфака я, писавший до того на Perl, был вынужден познакомиться с Python, потому что на нём была написана реализация формата хранения результатов экспериментов в кристаллографии :) Уже тогда он в хвост и гриву использовался научным сообществом. В отличие от personal home pages, только-только начавших стесняться своего названия и ставших акронимом. И лексического анализатора, созданного для тех, кому стало мало awk и sed :)
А ведь еще даже не было SciPy :)
pip freeze > all_requirements.txt
Руками вычистить опциональный пакеты и обозвать requirements.txt
Залить в репу и дальше уже тем кто ставит надо будет выполнить:
pip install -r requirements.txt
или
pip install -r all_requirements.txt
Нужны тулзы для автоматического создания и обновления “setup.py”. Ну или что-нибудь вроде “setup.python.json” или чего-нибудь подобного, чтобы не было необходимости писать код только ради пары строк метаданных.
На самом деле давно уже предлагают вообще избавиться от setup.py. Вот недавно даже PEP написали: https://www.python.org/dev/peps/pep-0518/
Лично моё мнение: wheel-пакеты — это лучшее, что случилось с инфраструктурой зависимостей Python за последнее время. Думаю, направление выбрано верное.
P.S. я сам питонист.
Они там приводят аргументы в защиту TOML, что он простой, гибкий и human-usable, что он используется в Cargo и т. д. JSON им кажется плохо читаемым, а YAML слишком сложным. Причем они не настаивают прямо вот на TOML (хотя и рекомендуют) и приводят примеры конфигураций также и на JSON/YAML. В любом случае, в Python из коробки сейчас есть только JSON.
2) Wheel — это zip-архив, как и многие другие схожие форматы (ну, вспомним хотя бы jar). Метеданные внутри архива — это другое дело, там JSON/YAML был бы в тему, но скорее всего формата ключ: значение на очень многие задачи будет хватать.
Остальное — оч-ч-чень интересно, надо пробовать и разбираться в деталях.
уже нельзя говорить, что у других языков программирования все «намного лучше»
Вот не обобщали бы на всех-то… это всегда выходит неправда.
Ну если по-простому — то почти у всех языков на платформе JVM намного лучше. Скажем, до groovy grapes Python еще далеко по удобству. Это вовсе не значит, что у Python все плохо — просто есть к чему стремиться. Я прекрасно понимаю, что если у вас зависимость это скажем native бинарники, а не portable код на Python — то этого не так просто добиться.
Скажем, вы можете написать:
!/usr/groovy/latest/bin/groovy
@Grapes([
@GrabConfig(systemClassLoader=true)
, Grab(group='net.sourceforge.jtds', module='jtds', version='1.3.1')
, Grab(group='org.postgresql', module='postgresql', version='9.3-1100-jdbc41')
, Grab(group='com.sybase', module='jconn3', version='6.05')
])
import groovy.sql.*
import net.sourceforge.jtds.jdbcx.*
т.е. динамически подключить зависимость (в данном случае — драйвер базы данных), и тут же ее импортировать и использовать.
Как правило, создатели нового языка программирования уделяют этому не очень много внимания… Единственным на моей памяти исключением является node.js
Немного непонятно почему здесь авторы node.js приравнены к авторам языка Javascript. Или это одни и те же люди?
Кроме того что многие зависимости рассчитывают на nightly или по крайней мере unstable.
Учитывая что нестабильный функционал есть только в ночных сборках, одного без другого не бывает.
Да и не так уж что бы и очень многие. Мне вот сходу только serde из популярных пакетов в голову приходит, и то у него есть костыли для сборки на стабильной версии компилятора.
но ведь никто из читающих эти строки не использует Rust?
Ну уж нет, как минимум один гордый растафарианин (или как там договорились самоназываться?) читает это. Пускай и только в хобби-проекте использую)
«Минусы:
1. Поставить библиотеку для обработки статистики оказалось делом не тривиальным (пришлось покопаться в инете), в итоге нужно скачать отсюда пакет (numpy-1.11.1+mkl-cp27-cp27m-win32.whl) для установки numpy и выполнить команду «pip install numpy-1.11.1+mkl-cp27-cp27m-win32.whl» в папке где лежит пакет.
»
Понимаете, не тривиальное это дело, собранное колесо поставить. А вы говорите зависимости.
Собрать numpy на Windows из исходников — нетривиальная задача. Поэтому есть неофициальные собранные пакеты с MKL. Без MKL есть официальные wheel-пакеты на PyPI, поэтому не понятно, что за сложности были у тех, кто давал тестовое задание. Возможно, это было давно, когда официальных wheel-пакетов ещё не было.
Сейчас, если не нужна производительность MKL, можно просто делать так:
pip install numpyА почему нельзя стандартно что-то вроде apt-get install python3-numpy-dev?
В репах обычно старая версия
pip install numpy
На винде это легко выливается в танцы с поиском и установкой нужного компилятора. Особенно на 64 битной системе. Может быть вот прямо сейчас это изменилось в лучшую сторону, но еще этой весной все было очень плохо.
Я выше пишу:
Собрать numpy на Windows из исходников — нетривиальная задача.
Сейчас на PyPI уже лежат официальные собранные wheel-пакеты под винду: https://pypi.python.org/pypi/numpy
Компилятор не нужен, там уже собранные бинарники в пакете.
Другое дело, что они собраны без MKL, а MKL сильно улучшает производительность вычислений над массивами.
Numpy+MKL для Windows обычно отсюда брали — полет нормальный ;)
Что касается virtualenv, как по мне это главная проблема в питоне. Virtualenv – софт с плохим дизайном, который даже не пытается решать проблемы предоставляя сложное решение с хаком консоли и копированием половины питона и при этом не позволяя выбирать в проекте версию интерпритатора. Чтобы использовать другой питон нужно ставить pyenv, который тоже имеет фатальный недостаток – отсутствие кроссплатформенности. Если бедный разработчик хочет чтобы его проект работал и под виндой тоже, есть и такие два пакета: pywin и anyenv. Ну и так дальше в глубь ада.
В общем количество альтернативных реализаций virtualenv показывает на проблемы инструмента, которые пока никто не решает.
Управление зависимостями в Python: похоже, уже можно пользоваться