-----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 [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
iD8DBQFGUuOw+gerLs4ltQ4RAiHTAJwL8XV3wdDdzcyKP6/PDbboerU8oQCeLdIj
w3R+bkVczZtCvOZXl19/Qjc=
=hqDF
-----END PGP SIGNATURE-----
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
