Компиляция моего собственного питона сломала системные скрипты?
(Для тех, кто не знаком с ним, 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
, но теперь я начинаю задумываться
- Это нормально для людей, которые катят свой собственный Python?
- Я как-то неправильно скомпилировал / настроил 2.7?
- Разумно ли ожидать, что пакеты, установленные с помощью apt-get/synaptic, будут "заблокированы" с версией зависимостей, с которыми они были установлены?
- Должен ли я каким-то образом переконфигурировать мой $PATH так, чтобы
/usr
файл найден до/usr/local
файл? - Должен ли я просто удалить файл жесткой ссылки /usr/local/bin/python и начать все мои скрипты с
#!/usr/local/bin/python2.7
? - Нужно ли вручную устанавливать все недостающие библиотеки и т. Д. Для
/usr/local
? Если так, каков наилучший способ сделать это? - Должен ли я сообщать об ошибках сопровождающим пакетов, самим проектам или обоим?
[1] Который, из-за того, как мой путь настроен, вызывает мой /usr/local/bin/python
(2.7), а не системы /usr/bin/python
(2.6)
1 ответ
Это достаточно нормально, так что большинство людей, которые создают свои собственные среды Python, используют что-то вроде virtualenv для управления ими. Замена предоставляемых системой Perl, Python или Ruby почти никогда не является хорошей идеей, и все три языка предоставляют разработчикам возможность управлять своими собственными частными установками (для Perl есть PerlBrew, а для Ruby есть RVM).