[OpenIndiana-discuss] Calibre doc converter to ebooks formats for OpenIndiana??

[Lou Picciano]

From: "Jan Owoc" <jsowoc at gmail.com> 
To: "Discussion list for OpenIndiana" <openindiana-discuss at openindiana.org> 
Sent: Thursday, August 9, 2012 9:37:32 AM 
Subject: Re: [OpenIndiana-discuss] Calibre doc converter to ebooks formats for OpenIndiana?? 
On Thu, Aug 9, 2012 at 7:03 AM, Milan Jurik <milan.jurik at xylab.cz> wrote: 
> Sooner or later Python 3.2 will be provided in OI SFE but I am not sure how 
> much it can coexists with 2.6 


<blockquote>

Many GNU/Linux distributions have both a Python2 and a Python3 in 
their repositories. I happen to have both installed on one of my 
systems. 
</blockquote>

<blockquote>


</blockquote>

<blockquote>

</blockquote>
We do quite a bit of 'experimentation' with various versions of Python, so have several versions installed at a given moment. The Python 'altinstall' option is your friend here through all v2s of python. In fact - if memory serves, since v3.0(?), I believe 'make install' is now an alias for 'make altinstall'. The 'make fullinstall' option now exists for when you're ready to make the jump to v3-as-default. 


Really, the developer has fully granular control over which binary to use in a given environment; they coexist quite nicely in separate trees. (Some crazy developer might well have 2.4, 2.6, 2.7 and 3.2, all in harmonious cohabitation.) 


Of course, the only big gotcha is that the binary named 'python' is called, by default, by many things - and so should be agreed upon. We can make the determination of which version is to be so blessed as 'The OS Version' as necessary bits and pieces make it into versions. 


Fwiw, I've suggested we use these binary naming conventions within our own userland builds; they seem to accommodate most developer use cases (we have many), and allow for rapid transition in the future; for example, for all the system-level uses of python. 



(OK, I had to look it up: see release notes for 3.0a5: http://www.python.org/getit/releases/3.0.1/NEWS.txt ) 

<blockquote>



The way it works is similar to how it's frequently done with gcc, 
where there is a series of symbolic links, with the plain "python" 
command pointing toward the version that is considered most universal: 


~$ ls -l /usr/bin/pyth* 
lrwxrwxrwx 1 root root 9 Apr 23 10:06 /usr/bin/python -> python2.7 
lrwxrwxrwx 1 root root 9 Apr 23 10:06 /usr/bin/python2 -> python2.7 
-rwxr-xr-x 1 root root 2989480 Jul 31 23:40 /usr/bin/python2.7 
-rwxr-xr-x 1 root root 1652 Jul 31 23:40 /usr/bin/python2.7-config 
lrwxrwxrwx 1 root root 16 Apr 17 11:20 /usr/bin/python2-config -> 
python2.7-config 
lrwxrwxrwx 1 root root 9 Apr 14 23:13 /usr/bin/python3 -> python3.2 
lrwxrwxrwx 1 root root 11 May 3 09:52 /usr/bin/python3.2 -> python3.2mu 
-rwxr-xr-x 1 root root 2954048 May 3 09:52 /usr/bin/python3.2mu 
lrwxrwxrwx 1 root root 11 Apr 14 23:13 /usr/bin/python3mu -> python3.2mu 
lrwxrwxrwx 1 root root 16 Apr 17 11:20 /usr/bin/python-config -> 
python2.7-config 


When I have a program that *requires* Python 3.2, it usually knows (or 
can be configured) to call "python3". 


Cheers, 
Jan 


_______________________________________________ 
OpenIndiana-discuss mailing list 
OpenIndiana-discuss at openindiana.org 
http://openindiana.org/mailman/listinfo/openindiana-discuss 
</blockquote>