Моя цель - распространять пакет Python с несколькими другими широко используемыми пакетами Python в качестве зависимостей. Мой пакет зависит от хорошо написанных пакетов с индексированием Pypi, таких как pandas, scipy и numpy, и указывает в файле setup.py, что необходимы определенные версии или более высокие из них. "numpy >= 1.5".
Я обнаружил, что для пользователей Unix, которые не являются экспертами в области упаковки Python (даже если они знают, как писать Python), это невероятно сложно и почти невозможно, чтобы установить пакет, такой как мой, даже при использовании того, что должно быть легко используйте менеджеров пакетов. Мне интересно, есть ли альтернатива этому мучительному процессу, который может предложить кто-то, или если мой опыт отражает очень сложное текущее состояние упаковки и распространения Python.
Предположим, пользователи загружают ваш пакет в свою систему. Большинство будет пытаться установить его "наивно", используя что-то вроде:
$ python setup.py install
Так как если вы указали инструкции Google по установке пакетов Python, это обычно происходит. Это провалится для подавляющего большинства пользователей, поскольку большинство из них не имеют корневого доступа на своих серверах Unix/Linux. С большим количеством поисков они обнаружат параметр "--prefix" и попробуйте:
$ python setup.py install --prefix=/some/local/dir
Поскольку пользователи не знают о тонкостях упаковки Python, они будут выбирать произвольный каталог в качестве аргумента для --prefix, например. "~/software/mypackage/". Это не будет чистый кураторский каталог, где все остальные пакеты Python будут проживать, потому что снова большинство пользователей не знают об этих деталях. Если они устанавливают другой пакет "myotherpackage", они могут передать его "~/software/myotherpackage", и вы можете себе представить, как в будущем это приведет к расстраиванию взлома PYTHONPATH и других осложнений.
Продолжая процесс установки, вызов "setup.py install" с помощью "--prefix" также завершится неудачей, если пользователи попытаются использовать пакет, даже если он был установлен правильно, поскольку одна из зависимостей может отсутствовать (например, pandas, scipy или numpy) и диспетчер пакетов не используется. Они попытаются установить эти пакеты по отдельности. Даже если они будут успешными, пакеты неизбежно не будут в PYTHONPATH из-за нестандартных каталогов, данных "--prefix", и пользователи-пользователи будут пытаться модифицировать их PYTHONPATH, чтобы получить зависимости, чтобы быть видимыми.
На этом этапе опытный знакомый Python может сказать, что они должны использовать диспетчер пакетов, например, "easy_install", основного менеджера, для установки программного обеспечения и выполнения зависимостей. После установки "easy_install", которые могут быть трудными, они попытаются:
$ easy_install setup.py
Это тоже не удастся, так как пользователи, как правило, обычно не имеют разрешения на установку программного обеспечения на глобальном уровне на производственных серверах Unix. С большим чтением они узнают о опции "--user" и попробуйте:
$ easy_install setup.py --user
Они получат ошибку:
usage: easy_install [options] requirement_or_url ...
or: easy_install --help
error: option --user not recognized
Они будут крайне озадачены, почему их easy_install не имеет опции --user, где есть четкие страницы в Интернете, описывающие эту опцию. Они могут попытаться обновить их easy_install до последней версии и обнаружить, что они все еще не работают.
Если они продолжатся и обратитесь к эксперту по упаковке Python, они обнаружат, что существуют две версии из easy_install, обе названные "easy_install", чтобы максимизировать путаницу, но одна часть" распространять "и другую часть" setuptools ". Бывает, что только "easy_install" из "distribute" поддерживает "--user", и подавляющее большинство администраторов серверов /sys устанавливают "setuptools" easy_install, и поэтому локальная установка будет Имейте в виду, что эти различия между "distribute" и "setuptools" бессмысленны и трудно понять для людей, которые не являются экспертами в управлении пакетами Python.
В этот момент я бы потерял 90% даже самых решительных, опытных и терпеливых пользователей, которые пытаются установить мой пакет программного обеспечения - и это справедливо! Они хотели установить часть программного обеспечения, которое, как оказалось, было написано на Python, а не стать экспертами в современном дистрибутиве Python, и это слишком запутанно и сложно. Они будут сдаваться и расстраиваться в то время, когда теряются.
Маленькое меньшинство пользователей, которые продолжают и спрашивают больше экспертов Python, будет сказано, что они должны использовать pip/virtualenv вместо easy_install. Установка pip и virtualenv и выяснение того, как эти инструменты работают и как они отличаются от обычных вызовов "python setup.py" или "easy_install", сами по себе являются трудоемкими и сложными, и снова слишком много, чтобы спросить у пользователей, которые просто хотели для установки простой части программного обеспечения Python и ее использования. Даже те, кто преследует этот путь, будут смущены относительно того, могут ли все зависимости, которые они устанавливали с помощью easy_install или setup.py install --prefix, использовать с pip/virtualenv или если все нужно переустановить с нуля.
Эта проблема усугубляется, если один или несколько рассматриваемых пакетов зависят от установки другой версии Python, чем тот, который по умолчанию. Трудность обеспечения того, чтобы ваш ящик пакета Python использовал версию Python, к которой вы хотите, и что необходимые зависимости устанавливаются в соответствующем каталоге Python 2.x, а не Python 2.y, будут настолько бесконечно разочаровывать пользователей, что они безусловно, откажутся на этом этапе.
Есть ли более простой способ установить программное обеспечение Python, которое не требует от пользователей ознакомления со всеми этими техническими деталями пакетов, путей и местоположений Python? Например, я не большой Java-пользователь, но иногда я использую некоторые инструменты Java и не помню, чтобы мне приходилось беспокоиться о зависимостях X и Y от программного обеспечения Java, которое я устанавливал, и я не знаю, как пакет Java (и я рад, что я этого не делаю), я просто хотел использовать инструмент, который был написан на Java.) Я вспоминаю, что если вы загружаете Jar, вы просто получаете его, и он имеет тенденцию работать,
Есть ли эквивалент для Python? Способ распространения программного обеспечения таким образом, который не зависит от того, как пользователи должны преследовать все эти зависимости и версии? Способ, возможно, скомпилировать все соответствующие пакеты во что-то самодостаточное, которое можно просто загрузить и использовать как двоичный?
Я хотел бы подчеркнуть, что это разочарование происходит даже с узкой целью распространения пакета на опытных пользователей Unix, что делает проблему проще, не беспокоясь о проблемах с кросс-платформой и т.д. Я предполагаю, что пользователи являются подкованными Unix, и могут даже знать Python, но просто не знают (и не хотят, чтобы их узнавали) об особенностях упаковки Python и множестве внутренних осложнений/соперничества разных менеджеров пакетов. Тревожной особенностью этой проблемы является то, что это происходит даже тогда, когда все ваши зависимости Python-пакета являются хорошо известными, хорошо написанными и ухоженными Pypi-доступными пакетами, такими как pandas, Scipy и Numpy. Это не похоже на то, что я полагался на некоторые неясные зависимости, которые не были сформированы правильно: скорее, я использовал самые распространенные пакеты, на которые многие могли бы положиться.
Любая помощь или совет по этому поводу будут очень признательны. Я думаю, что Python - отличный язык с большими библиотеками, но мне практически невозможно распространять программное обеспечение, которое я пишу в нем (после того, как оно имеет зависимости) таким образом, чтобы люди могли легко установить локально и просто запустить. Я хотел бы уточнить, что программное обеспечение, которое я пишу, не является библиотекой Python для программного использования, но программное обеспечение, в котором есть исполняемые сценарии, которые пользователи запускают как отдельные программы. Спасибо.
