[Pythonmac-SIG] python2.4, bdist_mpkg, matplotlib and data dir.

[Bob Ippolito]

On Jun 17, 2005, at 3:39 PM, Chris Barker wrote:

> Thanks for being so responsive, Bob.
>
> Bob Ippolito wrote:
>
>>> but when I use bdist_mpkg, they get put in:
>>>
>>> /usr/local/share/share/matplotlib
>>>
>>> Note the double "share".
>>>
>>
>> That's probably a bug, but it should probably happen with Python 2.3
>> also.  Can you reproduce there?
>>
>
> Actually, it seems to work fine with 2.3, for example the package I  
> just
> sent you was built that way. It's possible I've got an older  
> version of
> Py2App installed in 2.3 than 2.4, however. I've been selecting between
> them by doing:
>
> python2.3 /usr/local/bin/bdist_mpkg
> and
> python2.4 /usr/local/bin/bdist_mpkg
>
> so they are using the same script, but importing different Py2app  
> modules.
>
> on 2.3, the data's getting put inside the Framework, which sounds like
> the opposite of what you want, as the 2.3 framework is an Apple  
> supplied
> one.
>
> I just checked. In 2.3:
>
> py2app.__version__ = '0.1.7'
>
> In 2.4:
> py2app.__version__ = '0.2'
>
> I think I'll wait to update until I figure this out, no reason to  
> break
> 2.3 too!
>
>
>> For framework builds of Python, bdist_mpkg currently defaults scripts
>> and data into /usr/local instead of in-framework.  This is especially
>> important for the Apple framework, but not as much for the others.
>>
>
> I've always had this sort of problem with Linux too. When the vendor
> supplies a package, but you add non-vendor supplied add ons, where
> should you put them? On Linux, I've generally tried to put a link  
> inside
> /usr to somewhere inside /usr/local, so that I could integrate my add
> ons with the system stuff, without actually putting my stuff in the
> system directories. I've done this for python stuff and TeX stuff, for
> example.
>
> Apple set this up pretty well by making site-packages a link to
> /Library...., rather than just putting it in the system directories,
> like everyone else.

Doing symlinks is harder because that requires replacing even more  
distutils functionality.  I really don't care enough to go through  
that kinda trouble.  Patches accepted.

> perhaps bdist_mpkg could check if the Python is in a system library or
> not and put stuff in /Library somewhere if so, and inside the  
> Framework
> if not, or does that get too messy?

That's what it's doing, except it puts things in /usr/local, not / 
Library.  If it put things in /Library, nobody would ever find it  
because it's non-standard.  This is especially important for  
incorrect usage of data_files.  There is no way for a package to ask  
"where did my data files get installed?"  That is why using  
data_files is not the right idea for anything but extraneous junk  
(documentation, examples, etc.).  I chose /usr/local because it at  
least has a chance of being found at runtime; it's pretty common for  
packages to look there in addition to sys.prefix.  Semantically  
data_files is meaningless, so I couldn't default to some examples or  
documentation folder under /Developer or wherever (and that would  
also really punish incorrect usage).

The flip side is if the package is using data_files correctly (for  
examples, docs, etc.) but distutils installs it in-framework, then  
people would never find it... whereas with /usr/local they have a  
chance (especially for scripts).  Somewhere Finder-navigable would be  
better (for data_files), but I decided not to do that because there  
are too many dumb usages of data_files out there to make it worthwhile.

>> Using data_files in this manner at all is usually the wrong thing to
>> do anyway.  Python packages should really put the files they need
>> into the package, not some semi-random location on the filesystem.
>>
>
> You mean inside .../site-packages/matplotlib? Perhaps I'll ask John
> Hunter what his reasoning is.

Yes.  It used to be a PITA, but these days there is setuptools (or  
Python 2.4's distutils) which makes it trivial, so it's likely to be  
either ignorance or laziness.

-bob