On Wed, 24 Dec 2008 18:42:30 -0800 Danek Duvall <[email protected]> wrote:
> On Wed, Dec 24, 2008 at 08:41:30PM -0500, Mike Meyer wrote:
> > In that case, the problem is with your packaging system. If python
> > isn't supposed to be mucking around in python's library directories,
> > then who is?
> Absolutely nothing. Once a package is installed to a directory under /usr,
> /usr needs to be treated as read-only, as it very well may be mounted that
> way.
Mounting /usr read-only is an option I didn't consider, but would also
solve the problem.
> > 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. Suppressing the automatic creation of the pyc files was
the point of putting them in a zip file.
> > Once you bundle in the pyc files, it's no longer python version
> > independent - the pyc files won't work on other versions of python, and
> > someone with write permission running an other version will cause it to
> > be rewritten, making the checksums wrong, etc.
> Which is fine for the way we deliver python programs on Solaris, where
> everything is rebuilt with the python executable used to run the program,
> and the shebang statement points to a specific version of the python
> executable. I understan
I think you're missing the rest of the sentence.
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. Some python packages don't include an executable; they're
libraries used by applications from other packages. How do you insure
their pyc files are built with the right python, since they don't have
a shebang line to indicate which that might be (unless you added one
that is going to never be used)?
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? 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?
> > trying to treat pyc files as deliverables causes a build-time dependency
> > on the run-time python to appear. Unless you can guarantee that the only
> > run-time, then they're going to create problems
> I think you're missing a verb and object in there. But like I said, we do
> guarantee that components built with a certain version of python are also
> executed with it -- we don't just run /usr/bin/python and hope it's the
> right version.
No, you guarantee that the *executables* are run by the right
python. What do you do to guarantee that imported modules - which
where pyc's come from - are only imported by the right version?
> > Failing that, not delivering pyc files and having a way for the
> > packaging system to clean up files that it didn't deliver but might
> > have been created as part of the normal course of running the
> > application is probably second best.
> We already do this, but it's ugly, and if files are left behind in a
> directory the removed package didn't own exclusively, then there's no way
> to know that the files can be gotten rid of. I don't know whether "import
> foo" works if foo.pyc exists but not foo.py, but if so, then that's
> obviously bad behavior in such a situation.
If a pyc file is for your version, it will be used if there's not a
matching py file.
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.
For py/pyc files, you can always delete a pyc file if you're deleting
the matching py file, as the only way the pyc file could belong to a
different package is if a py file name collision occurred.
> > As a final option, if ON includes a recent enough version of Python
> > (the one they include is so old I no longer remember if it could do
> > this or not) is to put all the py files into a zip file that gets
> > properly added to the path, as python won't try and create pyc files
> > for files imported from a zip file.
> We could do that, but having the .py files out in the open is usually very
> useful, particularly when something goes awfully wrong, and you can help
> someone past the problem with a text editor.
Oh, I agree. I regularly curse emacs packages that fail to include the
.el files.
<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
