Компиляция моего собственного питона сломала системные скрипты?

(Для тех, кто не знаком с ним, CrunchBang в основном является предварительно сконфигурированным Debian Squeeze.)

Некоторое время назад я писал сценарий и хотел использовать функцию Python, представленную в 2.7. Поскольку последняя версия, которую я мог получить из репозитория Debian Squeeze, - это 2.6.6.8, я решил скачать последний исходный код и собрать его самостоятельно. После того, как я самостоятельно справился с зависимостями, я наконец-то заработал и закончил свой проект.

Однако с тех пор ряд системных скриптов перестали работать. Я заметил, что они (теперь сломанные скрипты) все начинаются с #!/usr/bin/env python[1] и зависят от одной или нескольких вещей, которые были установлены apt-get/synaptic, но связаны с Python 2.6. Несколько я исправил, вручную изменив заголовок на #!/usr/bin/python, но теперь я начинаю задумываться

  1. Это нормально для людей, которые катят свой собственный Python?
  2. Я как-то неправильно скомпилировал / настроил 2.7?
  3. Разумно ли ожидать, что пакеты, установленные с помощью apt-get/synaptic, будут "заблокированы" с версией зависимостей, с которыми они были установлены?
  4. Должен ли я каким-то образом переконфигурировать мой $PATH так, чтобы /usr файл найден до /usr/local файл?
  5. Должен ли я просто удалить файл жесткой ссылки /usr/local/bin/python и начать все мои скрипты с #!/usr/local/bin/python2.7?
  6. Нужно ли вручную устанавливать все недостающие библиотеки и т. Д. Для /usr/local? Если так, каков наилучший способ сделать это?
  7. Должен ли я сообщать об ошибках сопровождающим пакетов, самим проектам или обоим?

[1] Который, из-за того, как мой путь настроен, вызывает мой /usr/local/bin/python (2.7), а не системы /usr/bin/python (2.6)

1 ответ

Это достаточно нормально, так что большинство людей, которые создают свои собственные среды Python, используют что-то вроде virtualenv для управления ими. Замена предоставляемых системой Perl, Python или Ruby почти никогда не является хорошей идеей, и все три языка предоставляют разработчикам возможность управлять своими собственными частными установками (для Perl есть PerlBrew, а для Ruby есть RVM).

Другие вопросы по тегам