On Apr 21, 2012, at 3:49 AM, Martin Costabel wrote:
> On 20/04/12 23:11, Hans-Christoph Steiner wrote:
>>
>> Any thoughts on this? Any objections to me adding a bunch of 'systempython'
>> packages? I'm not entirely sure how to do this right, so any ideas are
>> helpful.
>
> I have had systempython packages for a couple of years. Here is my take on
> this:
>
> I have (basically) two systempython packages (`fink list systempython`):
> boost and pil. They are of different nature:
>
> boost1.3X-systempython has no python modules. It provides libraries (in
> header form, as static archives, and as dylibs) that use python for building.
> There was even a time when it didn't matter which kind of python was used for
> building. This is no longer the case, so I had to distinguish pythonXY
> (XY=25,26,27) and systempython variants. To make the shlibs packages
> compatible, I placed the dylibs into /sw/lib/pythonX.Y/site-packages for the
> pythonXY variants and into /sw/lib for the systempython variant. This is
> completely arbitrary, because they are dylibs, so they will be found by their
> install_name wherever that is.
>
> For pil-systempythonXY, this is different. This is a python module that needs
> to be found by python upon "import PIL". I decided to mimic the system python
> tree structure by introducing the directory /sw/Library/Python. This then
> contains X.Y/include and X.Y/site-packages subdirectories. One has to add
> /sw/Library/Python/2.5/site-packages to the runtime variable PYTHONPATH.
>
> This works nicely and is parallel to /sw/Applications (used by packages that
> produce apps) and /sw/Library/Frameworks (used by aquaterm). While the latter
> two (originally my invention, too) have been accepted by the fink validator,
> /sw/Library/Python is not yet officially accepted. I suggest to officialize
> it and to use it for other systempython packages.
>
> One problem with systempython modules is that the system python also comes in
> different versions. IIRC, the latest ('/usr/bin/python') is 2.5 for 10.5, 2.6
> for 10.6, and 2.7 for 10.7. But on all systems, earlier versions still exist.
> So if you do not want to make different systempythonXY variants for different
> distributions, you can use /usr/bin/python2.5 on all 3 supported OSX
> versions. For pil-systempython, which currently uses the latest version and
> therefore has different XY variants for different distributions, I will
> probably come back to using XY=25 for all 3 distributions.
I like the pil approach overall. I guess my only concern is using python2.5 on
all platforms, since 2.5 is pretty old. I guess that would be a good place to
start, since its probably the easiest to manage. Then if we find we need to
support newer versions of systempython, that could be added later.
.hc
----------------------------------------------------------------------------
"Making boring techno music is really easy with modern tools, but with live
coding, boring techno is much harder." - Chris McCormick
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
