-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
>> 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 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
-----END PGP SIGNATURE-----
Zope3-dev mailing list