Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

(For those not familiar with it, CrunchBang is basically a preconfigured Debian Squeeze.)

So a while back, I was writing a script and wanted to use a Python feature introduced in 2.7. Since the latest version I could get from Debian Squeeze's apt repo is 2.6.6.8, I decided to download the latest source and build it myself. After wrangling dependencies myself, I finally got something working, and finished my project.

However, since then, a number of system scripts have stopped working. I noticed that they (the now broken scripts) all start with #!/usr/bin/env python[1] and depend on one or more things that have been installed by apt-get/synaptic, but are associated with Python 2.6. A few I've fixed by manually changing the header to #!/usr/bin/python, but now I'm starting to wonder

  1. Is this normal for people that roll their own Python?
  2. Did I compile/set up 2.7 wrong somehow?
  3. Is it unreasonable to expect packages installed with apt-get/synaptic to 'lock in' with the version of dependencies they were installed with?
  4. Should I somehow reconfcd /igure my $PATH so that the /usr file is found before the /usr/local file?
  5. Should I just delete the hardlink file /usr/local/bin/python and have all of my scripts start with #!/usr/local/bin/python2.7?
  6. Do I have to manually install all of the missing libraries, etc. for /usr/local? If so, what's the best way to do this?
  7. Should I file bugs with the package maintainers, projects themselves, or both?

[1] Which, because of how my path is set up, invokes my /usr/local/bin/python (2.7) rather than the system's /usr/bin/python (2.6)

share|improve this question

1 Answer 1

This is normal enough that most people who build their own Python environments use something like virtualenv to manage them. Replacing the system-provided Perl, Python, or Ruby is almost never a good idea, and all three languages provide ways for developers to manage their own private installations (for Perl there is PerlBrew and for Ruby there's RVM).

share|improve this answer
    
That's awesome! I heard of virtualenv in the context of deployment, didn't realize it was useful for development, too. I'm guessing I don't want to use apt-get for this, either? So then I should delete /usr/local/binmkvir/python, mkvirtualenv -p /usr/local/bin/python2.7 dev and then workon X/deactivate? –  Nate Parsons Apr 25 '12 at 15:28
    
I'm not sure what you're asking (/usr/local/binmkvir/python looks slightly confused), but apt-get install virtualenv is fine. You do want to remove, or at least relocate, the python executable you had built and use virtualenv to install it properly so that you can use it without interfering with the system Python; see the virtualenv documentation. –  geekosaur Apr 25 '12 at 19:50
    
Whoops, by /usr/local/binmkvir/python I meant /usr/local/bin/python. Of course it's just my luck that I need v1.5.1+ to use Python 2.7, and the latest apt will give me is 1.4.9. I guess I have a ways to go. (and I must be blind, because I still don't see where in the docs it says to rm other pythons. The closest I see is Python's README saying to altinstall all but the primary version) –  Nate Parsons Apr 25 '12 at 21:52
    
It doesn't say that explicitly; it's implied by the fact that overriding the system-provided Perl/Python/Ruby is almost certain to break things (as indeed it did for you). "caution: fire is hot" –  geekosaur Apr 25 '12 at 22:04
    
So then why is the advice almost invariably to make install rather than make altinstall? It's like saying "put your computer in the fire" –  Nate Parsons Apr 25 '12 at 22:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.