Ну если вы пишете тесты на тайпчекинг, вам видимо нужно протестировать тайпчекинг) Обычно тестами тестируют реализованный функционал. Я не один проект на питоне запустил, и мне не пришлось ни разу писать тесты на тайпчекинг. Может конечно я что-то не так делаю) Но сейчас эти проекты прекрасно рефакторятся и расширяются. А тесты функционала помогают ничего не сломать. Ну и делается это все как минимум в 2 раза быстрее, чем было бы на той же Джаве)
Это все прекрасно покрывается тестами и проблемы с поддержкой и рефакторингом совсем небольшие. Ну и в Питона 3.5 завезли аннотации, если вам прям нужно знать типы, можете использовать такие подсказки. Один из основных плюсов Питона как раз в его динамической типизациии. А это позволяет не писать тонны интерфейсов явно, а использовать duck typing, что как раз и ускоряет разработку и поддержку в разы. Ну и тестирование автоматическое никто не отменял
Все зависит от задач и ресурсов. Разработка на Java как правило затратнее по времени, чем на Python. Но если есть критичные ко времени выполнения требования, тут да, Java может и лучше подойдёт. Но опять же, все зависит от задач и Питон отлично интегрируется с модулями на Си там, где нужна производительность. А если ещё вспомнить, что время разработчиков обходится значительно дороже, чем затраты на железо, тут вопрос может сместиться не в сторону Java. Не все так однозначно)
Это пока там только паспортные данные. Потом, если система взлетит и станет популярной, ничто не мешает расширить функционал и типы хранимых данных (кредитки, ключи и т. д.). "А почему бы и нет, система ведь надёжная, вон сколько народу пользуется и не опубликовано было взломов". А это уже далеко не безобидные паспортные данные. Полагаться на авось не стоит, даже когда данные не особо важные по вашему мнению. Есть уже давно проверенные алгоритмы шифрования с высокой криптостойкостью. Не нужно городить велосипед, чья криптостойкость ничем и никем не подтверждена. Ни к чему хорошему это, как правило, не приводит.
Вы правы, многое решает коллектив и люди вокруг. Если на ваше замечание о шуме и предложение переместится в переговорку не реагируют должным образом, кажется, что в данном случае не хватает взаимного уважения в коллективе
Я могу написать приложение, которое будет снимать вас в туалете, при этом маскироваться под видеочат к примеру. Вы позволите себя снимать? Обещаю, оно будет лучшим в категории "извращения". А снимать оно будет естественно только для улучшения своей статистики) Поставите?)
Ну, как я уже написал, это потенциальное поле для проблем) Если я набираю команду install, я ожидаю именно install, а не pin, deploy или ещё что-нибудь бонусом) В общем, в лучших антпаттернах Питона, потому как это совсем не explicit is better than implicit.
А что делать, если я хочу потестировать новый пакет, но пинить мне не надо? Обычно это поведение менеджеров по умолчанию, что npm, что pip и это вполне обоснованное решение. Если разработчик хочет зафиксировать версии пакетов, которые у него есть в о окружении и раскатить эти изменения на всех, и на прод в том числе, он должен сделать это явно. А такое поведение с фиксацией по умолчанию может сыграть злую шутку.
> а воспользоваться pipenv run То есть мне все команды запуска надо переделать? А если по какой то причине мне придется поменять инструмент, то менять команды запуска обратно. Ну да, весело наверное.
> Так и запишем!
Не стоит вырывать фразы из контекста. Я написал про альтернативу автоматической активации окружения, а не про управление зависимостями. Pyenv — это про разные версии интерпреторов и окружений на их базе и только. А pipenv в этом плане и жрец, и жнец, и на дуде игрец: и виртуальное окружение включит, и пакеты запинит, ещё и переменные окружения сам подгрузит, разве что пакет не собирает сразу под 3 платформы, и не деплоит их на сервера. А самое интересное, что без pip и virtualenv/venv он не работает, то есть по сути дублирует уже существующий функционал, но добавляет ещё расчет хэша, польза которого очень сомнительна, отделение зависимостей от явно установленных пакетов (похоже это единственный его плюс), ну и установку переменных окружения, которая к питону не имеет прямого отношения и тоже должна выполняться отдельными инструментами (поскольку, опять же, к питону напрямую не относится).
> Зачем себя ограничивать pyenv, а остальные вещи делать руками или другими способами — непонятно.
Ну если бы pipenv только управлял версиями и зависимостями в явном виде, то вопросов бы не было)
> На любой «платформе»? bash / zsh / cmd / powershell?
Насколько мне известно, да, поскольку вы прописываете его исполняемые файлы в PATH. Но я могу ошибаться, вам лучше ознакомиться с документацией.
> Нет Pipfile.lock — всегда ставит последние версии пакетов, если не указано иначе.
Вы так и не ответили на мой вопрос. Что значит «Strongly encourage the use of the latest versions of dependencies»? Об этом пишут разработчики инструмента на главной странице. Я лучше сначала разберусь, что это такое и как оно отразится на стабильности проектов, прежде чем использовать, тем более в проде ) Пока этот пункт мне непонятен.
> Никто не мешает использовать остальные тулзы.
Ну да, можно конечно. Только странно, что у вас переменные окружения будут выставляться 2 раза: сначала через pipenv, потом через другую тулзу, ну или наоборот, кто ж знает наверняка)) Даже не знаю, зачем вам такой костыль, но вам виднее) У всех разные запросы и задачи.
В заключение хочу сказать, что использование конкретного инструмента — дело сугубо индивидуальное. Но если мне нужно помимо менеджера пакетов, виртуального окружения и программы, которая подгружает переменные окружения ставить ещё инструмент, который делает всё то же самое, но не работает сам по себе ни без пакетного менеджера, ни без виртуального окружения, добавляет сомнительную функциональность, а также миграция на него и с него потребует немало времени (правка не только всех дев скриптов, но и скриптов развертывания), да ещё мне непонятны некоторые моменты в его философии, я наверное воздержусь.
Раньше нужно было делать несколько вещей и следить за ними самому (где создавался venv, активировал ли я его)
Насколько я понял из описания инструмента, окружение все равно надо явно активировать через pipenv shell, поэтому не понимаю, чем pipenv shell отличается от. venv/bin/activate к примеру. И там и там можно забыть активировать окружение.
pyenv же активирует окружение при входе в директорию проекта без всяких pipenv shell.
Поставить инструмент хуже, чем инструмент лучше? Странное предложение. Тем более, что pipenv умеет использовать pyenv, поэтому минусов никаких на выходе не получаем.
Начнем с того, что это разные инструменты) хотя их функционал может частично пересекаться. Поэтому писать, что один инструмент хуже, чем другой, хотя их сценарии и задачи отличаться, вот это действительно странно) Я лишь предложил pyenv в качестве альтернативы автоматической активации окружения.
Нет, не избыточно. Это автоматизация рутинного процесса в инструменте, который я буду использовать каждый день.
Ну если вы каждый день обновляете пакеты, то да, это нужный функционал. В моей практике обновление пакетов выполняется ну раз в месяц, не чаще. Не потому, что лень, а потому что процесс проверки и миграции занимает время, которое не хочется тратить, если нет значимых преимуществ от обновления.
А суть фичи не в этом, а в том, чтобы оповещать разработчика о версиях пакетов, которые известны наличием уязвимостей.
А можно про это поподробнее?) Как использование хешей для файлов может оповестить о наличии или отсутствии уязвимостей в коде?
Они "пинят", в Pipfile.lock. А коли же вы его потеряли — из Pipfile установятся последние версии пакетов
То что они пинят, я понял) Просто непонятно тогда, что значит "Strongly encourage the use of the latest versions of dependencies"
Он просто сделает внутри окружения доступным всё что есть в .env
Ну если вы используете только питон, наверное, да, хороший вариант. Но если что-то, что выходит за рамки этого языка, то увы, тут pipenv будет только мешать этим функционалом, потому что в одном месте вы будете использовать стороннюю тулзу, а в проектах на питоне pipenv. Но, в целом, конечно, дело вкуса.
Вдобавок, если вы обратили внимание, то этот pipenv позиционируется разработчиками именно как менеджер среды dev окружения "Python Dev Workflow for Humans". А поэтому использовать его в проде я бы не рискнул. А при использовании его только в дев окружении теряется весь смысл, потому что на прод деплоится это будет уже по-другому.
Я и не писал, что pipenv не поддерживает pyenv) Я вот ещё раз перечитал по вашей ссылке список фичей и для меня честно плюсы этого инструмента очень сомнительны по сравнению с остальными. Давайте пройдемся по каждому пункту отдельно:
- You no longer need to use pip and virtualenv separately. They work together.
Это реально проблема для разработчика? Ну поставьте pyenv, он решает эту проблему, да еще и добавляет возможность ставить любую версию питона и на базе него создавать окружения, автоматически их активировать при входе в папке, деактивировать при выходе и так далее без всяких доп. pipenv shell комманд.
Managing a requirements.txt file can be problematic, so Pipenv uses Pipfile and Pipfile.lock to separate abstract dependency declarations from the last tested combination.
Вот это должно стоять первым пунктом и пожалуй единственная стоящая фича всего проекта — разделение зависимостей от явно установленных пакетов. Но это решается и без pipenv. Может и не так элегантно) Но ставить только для этого отдельную тулзу как-то избыточно, что ли.
Hashes are used everywhere, always. Security. Automatically expose security vulnerabilities.
От установки изначально неправильного или подмененного пакета это никак не защищает.
Strongly encourage the use of the latest versions of dependencies to minimize security risks arising from outdated components.
А это вообще зло. С одной стороны, ребята пишут, что жестко пинят версии, а потом пишут, что поощряют использовать самые последние версии зависимостей. В моей практике, даже обновление зависимостей может повлечь неконтролируемое изменение поведения кода, поэтому обновлять зависимости, как и установленные пакеты, нужно очень осторожно. И лучше это делать явно, руками и поднимать версии на нужные, а не на самые последние. Поэтому это бы я записал не в преимущество, а скорее в недостаток.
Give you insight into your dependency graph (e.g. $ pipenv graph).
Эмм, ну да, полезная штука наверное. За более пятилетний опыт разработки на питоне не разу с такой проблемой не сталкивался. Но, если она реально у кого-то возникает, то да, тут без pipenv наверное не обойтись.
Streamline development workflow by loading .env files.
А включать в тулзу, которая управляет пакетами, функционал чтения и активации файлов, которые к управлению пакетами вообще не имеют никакого отношения, — по мне так моветон. Для этого есть direnv и аналоги, которые именно для этого и предназначены и работают не только для питона (я, например, использую его и для проектов на node, go и так далее). А зачем эта функция в менеджере пакетов, непонятно.
pip freeze > requirements.txt
pip install -r requirements.txt
Первая команда фиксирует, вторая — инсталлирует все запиненные версии. По поводу флага, никогда не сталкивался с такой сборкой питона в рабочих проектах, мы везде испоьэльзуем виртуальное окружение, и такой проблемы не наблюдаем. Но, если у вас такая проблема есть, то, да, наверное, pipenv тут поможет
Ну если вы пишете тесты на тайпчекинг, вам видимо нужно протестировать тайпчекинг) Обычно тестами тестируют реализованный функционал. Я не один проект на питоне запустил, и мне не пришлось ни разу писать тесты на тайпчекинг. Может конечно я что-то не так делаю) Но сейчас эти проекты прекрасно рефакторятся и расширяются. А тесты функционала помогают ничего не сломать. Ну и делается это все как минимум в 2 раза быстрее, чем было бы на той же Джаве)
Из IDE отлично подходит PyCharm или IntellujIdea с плагином Python.
Тут все, что в принципе может понадобиться https://pypi.org. Там и категории есть и поиск по ключевым словам
И неявного объявления переменных в питоне тоже нет. Это вы с JS перепутали.
В питоне нет неявного преобразования типов
Это все прекрасно покрывается тестами и проблемы с поддержкой и рефакторингом совсем небольшие. Ну и в Питона 3.5 завезли аннотации, если вам прям нужно знать типы, можете использовать такие подсказки. Один из основных плюсов Питона как раз в его динамической типизациии. А это позволяет не писать тонны интерфейсов явно, а использовать duck typing, что как раз и ускоряет разработку и поддержку в разы. Ну и тестирование автоматическое никто не отменял
Все зависит от задач и ресурсов. Разработка на Java как правило затратнее по времени, чем на Python. Но если есть критичные ко времени выполнения требования, тут да, Java может и лучше подойдёт. Но опять же, все зависит от задач и Питон отлично интегрируется с модулями на Си там, где нужна производительность. А если ещё вспомнить, что время разработчиков обходится значительно дороже, чем затраты на железо, тут вопрос может сместиться не в сторону Java. Не все так однозначно)
Это пока там только паспортные данные. Потом, если система взлетит и станет популярной, ничто не мешает расширить функционал и типы хранимых данных (кредитки, ключи и т. д.). "А почему бы и нет, система ведь надёжная, вон сколько народу пользуется и не
опубликованобыло взломов". А это уже далеко не безобидные паспортные данные. Полагаться на авось не стоит, даже когда данные не особо важные по вашему мнению. Есть уже давно проверенные алгоритмы шифрования с высокой криптостойкостью. Не нужно городить велосипед, чья криптостойкость ничем и никем не подтверждена. Ни к чему хорошему это, как правило, не приводит.Вы правы, многое решает коллектив и люди вокруг. Если на ваше замечание о шуме и предложение переместится в переговорку не реагируют должным образом, кажется, что в данном случае не хватает взаимного уважения в коллективе
Я могу написать приложение, которое будет снимать вас в туалете, при этом маскироваться под видеочат к примеру. Вы позволите себя снимать? Обещаю, оно будет лучшим в категории "извращения". А снимать оно будет естественно только для улучшения своей статистики) Поставите?)
> Так и запишем!
Не стоит вырывать фразы из контекста. Я написал про альтернативу автоматической активации окружения, а не про управление зависимостями. Pyenv — это про разные версии интерпреторов и окружений на их базе и только. А pipenv в этом плане и жрец, и жнец, и на дуде игрец: и виртуальное окружение включит, и пакеты запинит, ещё и переменные окружения сам подгрузит, разве что пакет не собирает сразу под 3 платформы, и не деплоит их на сервера. А самое интересное, что без pip и virtualenv/venv он не работает, то есть по сути дублирует уже существующий функционал, но добавляет ещё расчет хэша, польза которого очень сомнительна, отделение зависимостей от явно установленных пакетов (похоже это единственный его плюс), ну и установку переменных окружения, которая к питону не имеет прямого отношения и тоже должна выполняться отдельными инструментами (поскольку, опять же, к питону напрямую не относится).
> Зачем себя ограничивать pyenv, а остальные вещи делать руками или другими способами — непонятно.
Ну если бы pipenv только управлял версиями и зависимостями в явном виде, то вопросов бы не было)
> На любой «платформе»? bash / zsh / cmd / powershell?
Насколько мне известно, да, поскольку вы прописываете его исполняемые файлы в PATH. Но я могу ошибаться, вам лучше ознакомиться с документацией.
> Нет Pipfile.lock — всегда ставит последние версии пакетов, если не указано иначе.
Вы так и не ответили на мой вопрос. Что значит «Strongly encourage the use of the latest versions of dependencies»? Об этом пишут разработчики инструмента на главной странице. Я лучше сначала разберусь, что это такое и как оно отразится на стабильности проектов, прежде чем использовать, тем более в проде ) Пока этот пункт мне непонятен.
> Никто не мешает использовать остальные тулзы.
Ну да, можно конечно. Только странно, что у вас переменные окружения будут выставляться 2 раза: сначала через pipenv, потом через другую тулзу, ну или наоборот, кто ж знает наверняка)) Даже не знаю, зачем вам такой костыль, но вам виднее) У всех разные запросы и задачи.
В заключение хочу сказать, что использование конкретного инструмента — дело сугубо индивидуальное. Но если мне нужно помимо менеджера пакетов, виртуального окружения и программы, которая подгружает переменные окружения ставить ещё инструмент, который делает всё то же самое, но не работает сам по себе ни без пакетного менеджера, ни без виртуального окружения, добавляет сомнительную функциональность, а также миграция на него и с него потребует немало времени (правка не только всех дев скриптов, но и скриптов развертывания), да ещё мне непонятны некоторые моменты в его философии, я наверное воздержусь.
Насколько я понял из описания инструмента, окружение все равно надо явно активировать через pipenv shell, поэтому не понимаю, чем pipenv shell отличается от. venv/bin/activate к примеру. И там и там можно забыть активировать окружение.
pyenv же активирует окружение при входе в директорию проекта без всяких pipenv shell.
Начнем с того, что это разные инструменты) хотя их функционал может частично пересекаться. Поэтому писать, что один инструмент хуже, чем другой, хотя их сценарии и задачи отличаться, вот это действительно странно) Я лишь предложил pyenv в качестве альтернативы автоматической активации окружения.
Ну если вы каждый день обновляете пакеты, то да, это нужный функционал. В моей практике обновление пакетов выполняется ну раз в месяц, не чаще. Не потому, что лень, а потому что процесс проверки и миграции занимает время, которое не хочется тратить, если нет значимых преимуществ от обновления.
А можно про это поподробнее?) Как использование хешей для файлов может оповестить о наличии или отсутствии уязвимостей в коде?
То что они пинят, я понял) Просто непонятно тогда, что значит "Strongly encourage the use of the latest versions of dependencies"
Ну если вы используете только питон, наверное, да, хороший вариант. Но если что-то, что выходит за рамки этого языка, то увы, тут pipenv будет только мешать этим функционалом, потому что в одном месте вы будете использовать стороннюю тулзу, а в проектах на питоне pipenv. Но, в целом, конечно, дело вкуса.
Вдобавок, если вы обратили внимание, то этот pipenv позиционируется разработчиками именно как менеджер среды dev окружения "Python Dev Workflow for Humans". А поэтому использовать его в проде я бы не рискнул. А при использовании его только в дев окружении теряется весь смысл, потому что на прод деплоится это будет уже по-другому.
Я и не писал, что pipenv не поддерживает pyenv) Я вот ещё раз перечитал по вашей ссылке список фичей и для меня честно плюсы этого инструмента очень сомнительны по сравнению с остальными. Давайте пройдемся по каждому пункту отдельно:
Это реально проблема для разработчика? Ну поставьте pyenv, он решает эту проблему, да еще и добавляет возможность ставить любую версию питона и на базе него создавать окружения, автоматически их активировать при входе в папке, деактивировать при выходе и так далее без всяких доп. pipenv shell комманд.
Вот это должно стоять первым пунктом и пожалуй единственная стоящая фича всего проекта — разделение зависимостей от явно установленных пакетов. Но это решается и без pipenv. Может и не так элегантно) Но ставить только для этого отдельную тулзу как-то избыточно, что ли.
От установки изначально неправильного или подмененного пакета это никак не защищает.
А это вообще зло. С одной стороны, ребята пишут, что жестко пинят версии, а потом пишут, что поощряют использовать самые последние версии зависимостей. В моей практике, даже обновление зависимостей может повлечь неконтролируемое изменение поведения кода, поэтому обновлять зависимости, как и установленные пакеты, нужно очень осторожно. И лучше это делать явно, руками и поднимать версии на нужные, а не на самые последние. Поэтому это бы я записал не в преимущество, а скорее в недостаток.
Эмм, ну да, полезная штука наверное. За более пятилетний опыт разработки на питоне не разу с такой проблемой не сталкивался. Но, если она реально у кого-то возникает, то да, тут без pipenv наверное не обойтись.
А включать в тулзу, которая управляет пакетами, функционал чтения и активации файлов, которые к управлению пакетами вообще не имеют никакого отношения, — по мне так моветон. Для этого есть direnv и аналоги, которые именно для этого и предназначены и работают не только для питона (я, например, использую его и для проектов на node, go и так далее). А зачем эта функция в менеджере пакетов, непонятно.
pip freeze > requirements.txt
pip install -r requirements.txt
Первая команда фиксирует, вторая — инсталлирует все запиненные версии. По поводу флага, никогда не сталкивался с такой сборкой питона в рабочих проектах, мы везде испоьэльзуем виртуальное окружение, и такой проблемы не наблюдаем. Но, если у вас такая проблема есть, то, да, наверное, pipenv тут поможет
А если в вашей системе есть другой пакет, которому нужна другая версия yarl, pipenv эту ситуацию разрулит?
Я для фиксации версий есть pip freeze. Так что мне совсем непонятны преимущества данной тулзы)