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 Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to