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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
