egg and modpython

[Wensheng]

Paul Boddie wrote:
> Bruno Desthuilliers wrote:
> > Wensheng a écrit :
> > > I installed pysqlite2 using easy_install.
> > > and got this when using it from modpython:
> > > --------------------------------------------------------------------------------------------------
> > > Mod_python error: "PythonHandler etc.modpython"
>
> [...]
>
> I applaud you for studying the traceback in more depth than I can find
> the motivation for, Bruno. ;-) However, this looks like a program using
> some package installed by setuptools/easy_install needs to unpack that
> package when running.
>
> > > ExtractionError: Can't extract file(s) to egg cache
> >
> > > The following error occurred while trying to extract file(s) to the
> > > Python egg cache:
> >
> > >   [Errno 13] Permission denied: '/var/www/.python-eggs'
>
> And this wants to happen apparently in the home directory of the Web
> server user, whose rights may be somewhat limited. Or perhaps one has
> to initialise setuptools for any particular user by running it first as
> that user: something that isn't a particularly common thing to do with
> non-interactive users on UNIX-like systems.
>
> [...]
>
> > > Can peak developers fix this please?
> >
> > Why should they "fix" something that's
> > 1/ documented
> >     -> http://peak.telecommunity.com/DevCenter/EggFormats#zip-file-issues
>
> "The Internal Structure of Python Eggs / STOP! This is not the first
> document you should read!" A case of "Beware of the Leopard" perhaps?
>
> > 2/ not a an egg specific issue
>
> In my experience, most other package managers actually unpack their
> resources when invoked, rather than leaving the programs to attempt
> such things when running. Debian packages even compile the bytecode
> files to ensure that nothing tries (and fails) to write them to
> privileged locations afterwards.
>
> > 3/ really just a configuration/permission problem
>
> Which should have been solved when the package manager was invoked,
> especially since this was most likely done as root.
>
> [...]
>
> > > in the mean time, I just have to use old "download, unzip/untar &&
> > > python setup.py install" way.
> >
> > No - you have to read the manual and fix you configuration. FWIW, the
> > above traceback gives far enough clues (it's even written in all letters).
>
> The various ways to deal with this include running easy_install as the
> Web server user so that it can touch the directory and whatever else it
> needs, and perhaps to set up various permissions - something you
> wouldn't usually do; running easy_install with the --always-unzip flag
> when installing the package as root; using python setup.py install as
> usual.
>
> This situation looks either a lot like a use case whose popularity has
> been underestimated by the developers - intriguing given the number of
> people supposedly using setuptools for their Web application
> deployments - or a packaging mistake with the pysqlite2 .egg file.
> Either way, system packages rarely suffer from this kind of problem,
> and it's quite understandable (and justifiable) to consider this bad
> behaviour.
>
> > Or you may read easy_install's doc to avoid installing zipped eggs:
> > http://peak.telecommunity.com/DevCenter/EasyInstall#compressed-installation
>
> Perhaps the developers should reverse their defaults and emulate the
> usual behaviour of package managers, unfashionable as that may seem.
>
> Paul

Thank you for clarification and other info/sugguestions.

As I read the document, if package author set "zip_safe = false" in
their setup.py, there would be no such problem.

I also second the idea of making "--always-unzip" the default.

It's EASY_install and EZ_setup, should be EASY so that we don't have to
read the document:), right?

If it's turbogears, yes, I would definitely read the document, but a
package manager...