-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote: > On May 21, 2007, at 1:39 AM, Martijn Pieters wrote: > >> On 5/21/07, Gary Poster <[EMAIL PROTECTED]> wrote: >>> FWIW, I know zc.catalog but I'm certainly not an egg expert. But >>> this message looks like you are maybe sharing a Python for various >>> installations. Are you maybe using your system Python? Generally >>> not advised for development work...try a standalone one? >> Come again? Using the system python when developing has always been >> fine; > > No. It has never been fine for any aspect of development. If you > develop with your system Python and deploy with a custom environment, > then you've added a variable that is different between the two > environments. Also, system Python's are often hobbled in ways that > hurt development. > > I sometimes get really weird error reports that are traced to system > Pythons. People who report problems to me that result from using a > system Python make me angry and make me want to not answer their > questions or otherwise help them any more. > > System Python's have their place. The are appropriate for casual > Python users and small one-off scripts, but not much else IMO. > >> the recommendation has only applied to deployment situations in >> the past. The point is that using a manual, dedicated build for a >> deployment gives you full control over tweaking that build for best >> performance without interfering with other users of the interpreter on >> the same system. >> >> I run dozens of development instances on my laptop, all with the same >> Macports python 2.4 installation. Creating a separate python build for >> each of these would be impractical, to say the least. > > You don't have to use a Python per project to avoid the system > Python. Just create a separate from-source installation and use that > single installation. *Never* install anything into that > installation. Whether you are using eggs or not, any packages not > included in a Python build from source should be managed in your > project area. Of course, eggs make this easier. > > (IMO, it is also reasonable to include a Python build in a buildout, > as long as it automated and as long as you don't mind the extra disk > space usage and build time. I prefer to use a shared clean Python > myself.) > >> However, it appears that the switch to eggs requires additional >> precautions to avoid your python system to be 'polluted' with various >> Zope3 packages. Perhaps we should recommend using workingenv for >> development work instead? > > Yes, as others have mentioned, you should use workingenv or > buildout. (I wrote buildout because workingenv didn't provide enough > control or automation for my needs.)
I use virtual python for this, actually: the separate tree makes it possible to allow distutils / easy_install to "pollute" their own, private site-packages directory without my having to fight with sys.path. The cost there is a separate copy of the Python interpreter per runtime environment, plus a mess of symlinks. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUcfU+gerLs4ltQ4RAshBAKCdX1/0rZ4Fwj3aEfdlHVulDgZ5jQCgxbd0 VYBGtQsCnOvji6o5MJxEIRI= =UUJv -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
