On Wed, 24 Dec 2008 21:14:29 -0800 Danek Duvall <[email protected]> wrote:
> 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 -- Mike Meyer <[email protected]> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
