On Wed, Dec 24, 2008 at 10:49:01PM -0500, Mike Meyer wrote: > > > pyc files are *not* some kind of compiled file you can use like elc > > > or jar files. They're a caching mechanism used by the python > > > vm/compiler combo to improve performance. > > > > If they're truly cache files, then they should go in a directory > > guaranteed to be writable, such as something under /var. > > Why do they need to go somewhere that's guaranteed to be writable? The > system works just fine if you can't create pyc files. It just works > slower.
They need to go to a place that's the same from system to system. Either they're there in /usr, which has its own set of rules, or they go under /var, which has a different set of rules. If the rules for /usr are too constraining -- and it sounds like you're arguing they are -- then they should go under /var. > Note that shebang lines are generally irrelevant to this discussion. pyc > creation isn't done when you load a python program for execution, it's > done when you import a module to use in a program. Ah, I see what you're getting at. We have a /usr/lib/python2.4 directory and a /usr/lib/python2.5 directory, with modules compiled by and intended to be used by interpreters of the corresponding version. True, you could override the built-in defaults, but why would you? The shebang line simply allows an executable to specify which version it's delivered its private modules for, so that it doesn't have to deliver them for all Python versions. > In particular, how does it work for people who want to 1) deliver a > product that requires a recent version of Python and 2) deliver things > using the systems native packaging tools? If you need a newer version of Python than is available from Sun, you're free to deliver one, anywhere you like. I'd suggest, as above, that you make sure that its built-in sys.path / $PYTHONPATH include a versioned directory so that it has a chance to pick up version-dependent files before it wanders off elsewhere. > Is the package creation process going to pick up more bad habits from > GNU/Linux package systems, and insist on creating pyc files built by the > system Python? There's nothing about the packaging system that insists what files get packaged up. That's entirely up to the package creator. If you decide to deliver your .pyc files in a zip file, or not at all, you're free to do so. > It sounds like you have the standard "clean up a shared directory" > thing. What I'm talking about is an explicit list of files to be > deleted, that 1) aren't considered an error if they're missing, > because we may not have installed them, and 2) are deleted without > comment even if the checksum is wrong. Interesting -- a "shadow file". I think Stephen or I dreamed that up at some point, but decided it was too kooky, even for us. :) Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
