DjangoBB LoFi version

Полная версия: Помогите новичку... Не ставится python-xml...

Начало » Python для новичков » Помогите новичку... Не ставится python-xml...

1 2 3

Ferroman

Фев. 17, 2010 10:59:26

Мда. Спор уровня детского сада(дурак - сам дурак) продолжать не буду. Если есть доводы - приводите, поспорим.

Вообще-то приводить доводы - дело человека делающего утверждение, а только потом - отрицающее его.

Учитывая тот бардак, который имеет место быть в setuptools/distutils/distribute/pip/продолжите сами, я бы сильно поопасался этим пользоваться, если есть нормальный дистр, пакетная база которого нормально мэйнтэйнится.

1. Что значит “бардак”. В чём именно он проявляется?
2. Обычно, питоновские пакеты весьма медленно обновляются в дистрах. Обычно из-за того, что попадают в репы только те пакеты, которые используются другими пакетами. Джанга, например, в этот перечень не входит, а следовательно, сильно отстаёт от релиза.
3. Пакетировать самому? Зачем? Есть же готовые способы установки/обновления, так зачем же надо оборачивать и так нормальные пакеты ещё раз?

Фев. 17, 2010 11:16:09

Ferroman
1. Что значит “бардак”. В чём именно он проявляется?

Да хотя бы в невозможности удалить поставленное с помощью easy_install. Вся эта куча тулзов, каждая из которых вроде как выглядит как решение, а на деле делает что-то нормально, что-то не делает вообще, а что-то плохо. Это и есть бардак в моем понимании.

2. Обычно, питоновские пакеты весьма медленно обновляются в дистрах. Обычно из-за того, что попадают в репы только те пакеты, которые используются другими пакетами. Джанга, например, в этот перечень не входит, а следовательно, сильно отстаёт от релиза.

Зависит от дистра. Но в общем не вижу в этом большой проблемы. Возьмем данный конкретный случай. Вы уверены, что топикстартер попросил распоследний python-xml? Что его не устроит то, что есть у него в дистрибутиве?
Вот вам пример как я ставлю openerp-client (что в общем-то и хотел топикстартер):

$ sudo apt-get install --dry-run openerp-client
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libgnomekbd3 console-terminus libclutter-gtk-0.8-0 xulrunner-1.9 libexiv2-5 gir1.0-gtk-2.0 libclutter-0.8-0 libkadm5clnt6 liblzma0 libavahi-gobject0
  libpoppler4 gir1.0-clutter-0.8 gnome-js-common libmozjs1d console-setup libclutter-cairo-0.8-0 libxklavier12 libmaa1 xulrunner-1.9-gnome-support
  gir1.0-freedesktop gir1.0-glib-2.0 libnautilus-burn4
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libhippocanvas-1-0 python-hippocanvas
Suggested packages:
  openerp-server
The following NEW packages will be installed
  libhippocanvas-1-0 openerp-client python-hippocanvas
0 upgraded, 3 newly installed, 0 to remove and 258 not upgraded.
Inst libhippocanvas-1-0 (0.3.0-3+b1 Debian:testing)
Inst openerp-client (5.0.6-2 Debian:testing)
Inst python-hippocanvas (0.3.0-3+b1 Debian:testing)
Conf libhippocanvas-1-0 (0.3.0-3+b1 Debian:testing)
Conf openerp-client (5.0.6-2 Debian:testing)
Conf python-hippocanvas (0.3.0-3+b1 Debian:testing)

С сервером тоже самое, уверяю вас.

Это хуже, чем собирать по углам распоследние версии python-xml, python-hippocanvas
и что там ему еще понадобится? Сильно сомневаюсь.

3. Пакетировать самому? Зачем? Есть же готовые способы установки/обновления, так зачем же надо оборачивать и так нормальные пакеты ещё раз?

Чтобы интегрировать их в более зрелую систему пакетов, естественно. От того, что вы смешаете нативные пакеты дистра и питоновые яйца ничего, кроме бардака не будет. Впрочем на вкус и цвет, как говорится …

Ferroman

Фев. 17, 2010 11:37:19

Да хотя бы в невозможности удалить поставленное с помощью easy_install. Вся эта куча тулзов, каждая из которых вроде как выглядит как решение, а на деле делает что-то нормально, что-то не делает вообще, а что-то плохо. Это и есть бардак в моем понимании.

Тогда как так получилось, что у меня с этим “бардаком” не было проблем? То же удаление не понадобилось ни разу. Хотя, может вам оно и надо…
Всё равно не даёт вам права заявлять о том что такой подход - плохое решение. Это не так.

Вы уверены, что топикстартер что попросил распоследний python-xml?

Я уже давал джангу как пример. Да и тот же python-xml в моей убунте в репах не значится. Как и на серверном дебиане.

Это хуже, чем собирать по углам распоследние версии python-xml? Сильно сомневаюсь.

Тянуть с официальных источников трудно назвать “собиранием по углам”. Да и что за риторика такая?

Чтобы интегрировать их в более зрелую систему пакетов, естественно.

Желание хорошее, может вам так удобнее. Но не надо говорить что другие способы плохи только потому что вам так кажется.
Я предпочитаю всё ставить из яиц, не используя пакеты дистрибутива. Никакого барда не наблюдаю.

Фев. 17, 2010 11:43:58

Дальнейший спор считаю бессмысленной тратой времени. Вам удобно так, мне эдак. У меня тоже все работает и нет проблем. Мы ничего друг другу уже не докажем. Предлагаю на этом завершить бессмысленное сотрясание воздуха.

Ferroman

Фев. 17, 2010 12:22:22

Скорее “марание бумаги” хе хе хе.
Смысл был не в том, чтобы вам что-то доказать, а в том, что бы у читающих тред не сложилось впечатление что есть один и только один Ъ путь.

Фев. 17, 2010 13:28:00

Собственно изначально не шла речь о единственном пути. Если помните, я в самом начале сказал, что вначале нужно попробовать найти пакет, который уже интегрирован в дистр, а уже потом, подумавши, и если очень хочется то можно и easy_install заюзать.
Я правильно понял, что вы хотите продолжить словопрения :) ? У меня в общем-то есть что сказать читающим тред.

Ferroman

Фев. 17, 2010 14:13:33

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

Вот. Я же придерживаюсь прямо противоположной точки зрения.

Я правильно понял, что вы хотите продолжить словопрения smile ?

Я думал, мы уже все высказали своё мнение.

У меня в общем-то есть что сказать читающим тред.

Раз есть что сказать, говорите конечно. Не держите в себе ;) .

Фев. 17, 2010 14:48:54

Я лучше вопросы задам :) Вы мне на них ответите и я побегу переставлять все easy_install-ом :)
1. В моем дистре вот что у меня есть по поводу django:

$ apt-cache show python-django |grep ^Version:
Version: 1.2~beta1-1
Version: 1.1.1-3
Version: 1.0-1
Version: 0.96.1-3.1
Version: 0.96.1-3

Если мне нужна Django, то мне лучше ставить ее из pypi? Что это мне даст? Какие пакеты она притащит по зависимостям?

2. Если мне через некоторое время Django перестанет быть нужной, то как мне ее и все, что она притащила за собой удалить?
3. Как мне увидеть список установленных python eggs с версиями?
4. Как мне заапгрейдить установленные eggs на более свежие версии, которые есть в pypi? Я имею в виду нечто подобное apt-get upgrade или dist-upgrade.
5. Что произойдет, если у меня стоит пакет из pypi и его же потребовал другой пакет, который я ставлю пакетным менеджером из моего дистрибутива? Узнаю ли я о конфликте?
6. Как мне найти документацию на egg, который у меня установлен?
7. В pypi масса eggs в стадии alpha или beta. Как я могу сделать так, чтобы не ставить их на production?
8. Каким образом происходит удовлетворение runtime зависимостей на непитоновый софт для пакетов из pypi? Каким образом easy_install узнает что у меня уже установлено с помощью моего package менеджера или не установлено?
9. Каким образом я смогу получить информацию об изменениях между версиями a и b для некоего egg?
10. Что делать с версией python по умолчанию для дистрибутива и тем, что потребует некий egg? Поставить новый python не проблема, как сделать так, чтобы он вызывался, когда в скрипте написано /usr/bin/env python и при этом не сломать остальной софт, который все еще хочет старый python?

и т.д.

Ferroman

Фев. 17, 2010 15:37:33

1. В моём нету. Менять из-за этого дистр?
2. Уже говорил, что не имел потребности удалять пакеты. Но это достаточно просто
easy_install -m
3. yolk -l
4. Все сразу? Я не знаю как вы, а я апдейчусь на новую версию библиотеки только по необходимости. Тем не менее
yolk -U - покажет наличие новых версий.
easy_install –upgrade SomePackage - обновит нужный пакет.
5. Не знаю. Скорее всего нет, ибо питон сначала будет искать у себя, а уже потом во внешних путях.
6. pydoc SomePackage
7. Ставьте только те, что надо. При установке можно указать версию.
8. Никак. И он не знает. Они все ставятся в разные места. Я, не вникал, но и проблем не встречал.
9. Наверное в документации пакета или на странице pypi. Вы ведь не обновляетесь “просто так”?
10. Я не совсем понял вопрос. У меня стоят сейчас 3 версии питона с разными наборами “яиц”. Для каждого свой. /usr/bin/env python будет брать системный питон. Если надо другой - это надо указать.
Только какое это имеет отношение к предмету разговора?

Обратный вопрос:
Вы когда удаляете питоновский пакет, у которого есть в зависимостях другой питоновский пакет и этот пакет у вас в девелопменте используется, то как вы удалете один и оставляете другой?

Фев. 17, 2010 16:17:30

1. Вы не ответили на вопрос. Нет, не менять.
2. Я же не только для вас пишу. По-моему удаление - это вполне обычная операция.
“After you've done this, you can safely delete the .egg files or directories, along with any scripts you wish to remove.” - Гы :). Я себе представляю эту незатейливую операцию на кластере машин в несколько десятков.
3. Не слышал о таком. Еще одна полузаброшеная тулза по виду. И это лучше, чем нормальный package management?
4. Речь идет о продакшене. Я использую стабильную ветку дистра и ставлю все апдейты, включая и питоновые с помощью apt-get upgrade. Проблем ни разу не было. Попакетное обновление в данном случае является по моему мнению пустой тратой времени.
7. Очень непроизводительно. Я лучше потрачу это время на пакетирование тех нескольких пакетов, которых нет в дистре :)
9. Нет, я не обновляюсь просто так. см.4 Для пакетов из дистрибутива я могу посмотреть changelog, который приходит вместе с пакетом. Не нужно никуда ходить.
10. Речь идет о том, что в дистрибутиве как правило есть версия питона по умолчанию и достаточная доля уверенности, что большинство пакетов оттуда будут с ней работать. Как только это разбавляется софтом из pypi я не понимаю как за этим следить. Не лазить же в питоновые файлы руками и править там /usr/bin/env python на /usr/bin/env python<версия> в самом деле.
И да, это имеет самое прямое отношение к предмету разговора.

Обратный вопрос:
Вы когда удаляете питоновский пакет, у которого есть в зависимостях другой питоновский пакет и этот пакет у вас в девелопменте используется, то как вы удалете один и оставляете другой?

Я наверное не понял вопроса. То есть мне перестал быть нужен пакет a, но он зависит на b, который мне нужен? Беру и удаляю a. apt-get remove a.