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.
I spent a few minutes thinking about putting them in var, and - well,
it looks like a major headache, what with multiple versions of Python
and relative imports. And yes, I believe your rules for /usr are to
constraining - mostly because you're trying to build the .pyc files
into the package instead of on delivery. However, if you want to file
a PR with the PSF stating that the current behavior is broken, I'd be
interested to hear what they have to say about it - or maybe only the
first few rounds...
> > 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 isn't what gets created that's the problem, it's what doesn't get
cleaned up. I believe the right way to handle pyc files is to create
them at installation time or dynamically as the application runs;
packaging systems that want them in the package - or won't clean them
up properly afterwards - have been a constant source of problems for
me.
> > 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. :)
I can't think of anything else that has this kid of "cache file" that
1) needs to be closely linked to an original data file and 2) is
generally static after it's been created.
<mike
--
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
