[Zope3-dev] Re: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marius Gedminas wrote:
> On Mon, May 21, 2007 at 12:21:42PM -0400, Tres Seaver wrote:
>> Reinoud van Leeuwen wrote:
>>> On Mon, May 21, 2007 at 10:39:22AM -0400, Fred Drake wrote:
>>> As a developer it might be a good idea to have different installed pythons 
>>> in different environments to be sure that some modules (or python itself) 
>>> meet different requirements. 
>>>
>>> But as system maintainer I like to keep things simple. I do not want 
>>> similar trees of python installations all over the place if it can 
>>> be avoided. 
>> Just as with Java-based applications:  if the server's job includes
>> running Zope, then installing a separate Python interpreter is a pretty
>> low cost, with the following benefits:
>>
>>  - You don't risk breaking your production Zope application in a
>>    distro-mandated upgrade to Python (e.g., Fedora 7 puts Python 2.5
>>    into /usr/bin/python).
> 
> That's probably the best reason.  I ran away from Debian's Zope 2.x
> packages because they made upgrades painful.
> 
>>  - You may not want to pay the cost of a Python optimized for desktop
>>    applications (UCS-4, anyone?)
> 
> Do you have any numbers?  How much memory of a typical Zope 3 app is
> taken by Unicode strings?  (I'm not trying to invalidate your argument,
> I'm genuinely curious.)

No hard numbers, except a vague recollection of shock at the difference
in two appservers running the same application, where one was running
using a UCS-4 interpreter.  Given that pretty much *all* ZPT rendering
these days involves Unicode manipulation, lots of the "transient" memory
used while rendering a page (as opposed to the ZODB cache) is
potentially affected.

>>  - You may need to patch Python to work around a bug which is only
>>    problemnatic for long-running Python instances (e.g., the
>>    longstanding cgi.FieldStorage DoS problem).
> 
> I don't think that's a good example.  I'd rather patch Zope in this
> particular case.

De gustibus, I guess.  Patching Python to work around issues which
affect your own application, but where the patch may languish in the SF
tracker for more than a year seems reasonable to me.   #112549 comes to
mind, for instance:  although reported against Python 2.3 while 2.3 was
still in maintenance, the fix never did make it into a 2.3 release, and
missed three third-dot revisions on the 2.4 side.

>>  - You can create a repeatable environment for testing each deployed
>>    application, even where those applications are running on boxes
>>    with different OS / distro-supplied Pythons.
> 
> There's still a point where you stop, right?  You don't have a
> self-compiled libc and a self-compiled C compiler to make sure your
> self-compiled Pythons are really identical?

I don't go that far (yet ;), but I often do end up building other
non-Zope components:

  - libxml2/lxml, for instance, because the OS-provided one has
    typically been too old, and because getting the Python wrappers
    built any other way is a nightmare

  - postgres, because I want to use Python as a stored procedure
    language.

  - Squid3 for ESI.

  - (hypothetically) Apache + mod_python, because it hard-wires the
    location of the Python iterpreter / DLLs.

The end result is that we can develop on laptops (Linux or Mac) and
deploy to production boxes (various Linux flavors, FreeBSD) with a fair
amount of confidence that the pieces all work as expected;  the
platform-specific bits all get manaaged as part of the buildout libraries.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
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

iD8DBQFGUuOw+gerLs4ltQ4RAiHTAJwL8XV3wdDdzcyKP6/PDbboerU8oQCeLdIj
w3R+bkVczZtCvOZXl19/Qjc=
=hqDF
-----END PGP SIGNATURE-----