In case anyone is still interested in this topic, a caveat on compiling 
Python, at least on Ubuntu and related distros. Compiling with standard 
configuration creates /usr/local/bin/python, which can cause problems with 
system utilities.

On Linux Mint 13, after rolling my own Python,  I ran into a problem where 
Cinnamon desktop manager would not load its settings screens. Turned out 
that it was calling just plain old `python`, not `/usr/bin/python`, so it 
was getting /usr/local/bin/python which did not have some expected modules 
installed. Deleting /usr/local/bin/python, which is a symlink to python2.7, 
corrected the fault.

Also: if you have /usr/local/bin/python, then `sudo python`, `sudo 
easy_install`, etc will not call the same executables as `python` and 
`easy_install`.



On Thursday, June 14, 2012 10:28:05 PM UTC-4, Chris McDonough wrote:
>
> On 06/14/2012 09:24 PM, Eric Ongerth wrote: 
> > Seems unnecessarily scary to newcomers to mention compiling your own 
> > Python early in the docs, even if we know it's no big deal. 
> > Particularly when the main concern at hand (that many people's system 
> > instance of python tends to be a poor choice for their Pyramid 
> > development) is easily and almost trivially solved by using a 
> > virtualenv. 
>
> It would be unnecessarily scary if it was unncessary, but like I 
> mentioned in the text included in this email it is effectively necessary 
> on some platforms. 
>
>   Would it not be enough to simply phrase the 
> > recommendation of using a virtualenv in fairly strong terms?  With a 
> > reference to a deeper document location that discusses the compile-yer- 
> > own-python approach for those interested. 
>
> No, it's a separate issue. 
>
> - C 
>
>
> > 
> > - Eric 
> > 
> > 
> > On Jun 13, 6:21 am, Chris McDonough<[email protected]>  wrote: 
> >> On 06/12/2012 06:36 PM, Wade Leftwich wrote: 
> >> 
> >>> With the Pyramid docs in ebook form on my phone I tend to browse them 
> >>> at odd times. Today, standing in line at the post office, I stopped at 
> >>> this paragraph right near the beginning: 
> >>> """ 
> >>> It s useful to use a Python interpreter that isn t the system Python 
> >>> interpreter to develop your software. The authors of Pyramid tend not 
> >>> to use the system Python for development purposes; always a self- 
> >>> compiled one. Compiling Python is usually easy, and often the system 
> >>> Python is compiled with options that aren t optimal for web 
> >>> development. 
> >>> """ 
> >>> ... and wondered what the best compilation options for web development 
> >>> might be. I generally use whatever comes with Ubuntu, which seems to 
> >>> work OK. Does anyone have config tips to share? 
> >> 
> >> That wording should probably be revisited because you're not the first 
> >> to ask.  More accurate is the statement "it's a real pain in the ass 
> >> when someone walks into IRC and gives us a Python compilation scenario 
> >> that can only be replicated with their particular OS/platform 
> combination". 
> >> 
> >> This tends to happen all the time on Mac, in particular, and fairly 
> >> often on Ubuntu as well.  This is usually because OS vendors tend to 
> >> actually use the system Python and consider it more "part of the OS" 
> >> than a development tool for third-party developers.  OS vendors don't 
> >> compile Python for usage by you; they compile it and configure it for 
> >> usage by themselves.  Their requirements may not be yours. 
> >> 
> >> I don't use a Mac anymore, but when I did, and when I tried to help 
> >> people get things running on their system Python, I was continually 
> >> surprised by the number of things that went wrong and the amount of 
> time 
> >> people would spend trying to fix them without just compiling and 
> >> installing another Python.  If I sat down at a machine and tried to 
> make 
> >> the system Python work with Pyramid, with enough time and effort, I 
> >> probably could.  But someone new to Python probably could not, at least 
> >> within a reasonable amount of time, and in that case, it's literally 
> >> easier to just compile another one. 
> >> 
> >> There's not one cause; each combination of Python version/OS 
> >> version/platform combination tends to have its own set of endearing 
> >> niggles that aren't much fun.  In general, it's just a shortcut to 
> >> consider the "system" Python the domain of the OS vendor and compile 
> >> your own Python for your own work to shortcut all the potential 
> landmines. 
> >> 
> >> For example, Python on Ubuntu has the following default sys.path: 
> >> 
> >> Python 2.7.3 (default, Apr 20 2012, 22:39:59) 
> >> [GCC 4.6.3] on linux2 
> >> Type "help", "copyright", "credits" or "license" for more information. 
> >>   >>>  import sys 
> >>   >>>  sys.path 
> >> ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', 
> >> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', 
> >> '/usr/lib/python2.7/lib-dynload', 
> >> '/usr/local/lib/python2.7/dist-packages', 
> >> '/usr/lib/python2.7/dist-packages', 
> >> '/usr/lib/python2.7/dist-packages/PIL', 
> >> '/usr/lib/python2.7/dist-packages/gst-0.10', 
> >> '/usr/lib/python2.7/dist-packages/gtk-2.0', 
> >> '/usr/lib/pymodules/python2.7', 
> >> '/usr/lib/python2.7/dist-packages/ubuntu-sso-client', 
> >> '/usr/lib/python2.7/dist-packages/ubuntuone-client', 
> >> '/usr/lib/python2.7/dist-packages/ubuntuone-control-panel', 
> >> '/usr/lib/python2.7/dist-packages/ubuntuone-couch', 
> >> '/usr/lib/python2.7/dist-packages/ubuntuone-installer', 
> >> '/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol'] 
> >> 
> >> Note the inclusion of Ubuntu-specific locations by default.  This isn't 
> >> a problem unless you don't use a virtualenv.  But some (insanely) 
> don't. 
> >>    I've seen some weird things happen as the result of these 
> nonstandard 
> >> dirs being included on sys.path by default in any case. 
> >> 
> >> The system Python on Ubuntu (and many other Linux distros) is also 
> >> compiled with UCS4 Unicode, which effectively doubles the space 
> required 
> >> in memory for each Unicode string without much benefit, as the 99% case 
> >> for webapps doesn't include characters outside the UCS2 range (at least 
> >> if those webapps don't use Asian scripts). 
> >> 
> >> - C 
> > 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/IFQelnUOVA8J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to