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

2007-06-27 Thread Andreas Jung



--On 27. Juni 2007 11:36:23 -0300 David Pratt <[EMAIL PROTECTED]> wrote:


Hi. I've tended to use system python against some better advice, but use
but leave it clean since I am using buildouts. This really has had more
to do with the convenience of using the system package tools for
upgrading such as FreeBSD ports system. I've also been experimenting with
CentOS and Fedora Core - so here yum comes into play.

I think the best advice I have got from the discussion seems to be using
a hand compliled python. I am almost at a point of thinking perhaps it my
be best to use cmmi recipe for most system software on a stripped down
server. I already need to patch a compiler and lxml will also only run on
most up-to-date xml libraries so building these seems to make sense to
make sure it does not choke.



...as Jim taught the audience during his Buildout tutorial some weeks
ago in Potsdam: """System Python is EVIL, EVIL, EVIL"""

Andreas

pgpGQeLsAKUQb.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



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

2007-06-27 Thread David Pratt
Hi. I've tended to use system python against some better advice, but use 
but leave it clean since I am using buildouts. This really has had more 
to do with the convenience of using the system package tools for 
upgrading such as FreeBSD ports system. I've also been experimenting 
with CentOS and Fedora Core - so here yum comes into play.


I think the best advice I have got from the discussion seems to be using 
a hand compliled python. I am almost at a point of thinking perhaps it 
my be best to use cmmi recipe for most system software on a stripped 
down server. I already need to patch a compiler and lxml will also only 
run on most up-to-date xml libraries so building these seems to make 
sense to make sure it does not choke.


The number of system packages I really need is limited and I am 
beginning to see more complex buildouts for apache for its configuration 
also:


http://svn.thomas-lotze.de/public/buildout-recipes/apache

Custom recipes are reasonable to assemble.

Has anyone any opinion on whether these are sane thoughts. On the plus 
side having complete control on a minimal software situation on a 
stripped server is attractive. On the other side the convenience of 
ports packages or yum are quite nice but potentially bring in other 
software you don't want or could potentially break a production setup. 
Updates and patches are certainly possible with buildout. Is this taking 
things too far in practice?


I see ruby's Capistrano doing much of the same jobs as zc.buildout - 
perhaps it has been around longer - but at the same time most setups I 
see still involve initial system software setup using yum with 
Capistrano doing the rest. Many thanks.


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



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

2007-05-23 Thread Brian Sutherland
On Wed, May 23, 2007 at 09:37:33AM +0200, Philipp von Weitershausen wrote:
>  Marius Gedminas wrote:
> > On Mon, May 21, 2007 at 10:44:47AM -0400, Jim Fulton wrote:
> >> On May 21, 2007, at 1:39 AM, Martijn Pieters wrote:
> >>> 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.
> > I'd love to hear some anecdotes about this.  The ones I know about:
> >   * distros releasing newer point versions of Python with security fixes
> > (cgi.FieldStorage) that break Zope 3
> 
>  I consider that a major show-stopper. An innocent "apt-get upgrade" pulls in 
>  Python 2.4.4c0 and all of a sudden all your Zope apps break! Well not mine, 
>  I use self-compiled Pythons for my production servers...

Was that a security update to a "released" version? Otherwise it's not
so innocent for a production system;)

btw, in future, it is planned to integrate the zope3 tests with
autopkgtest, http://packages.debian.org/unstable/devel/autopkgtest.

Which should mean that this kind of breakage will happen less as
autopkgtest basically is running the tests of installed packages on
installed packages.

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



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

2007-05-23 Thread Chris Withers

Tres Seaver wrote:

  - Squid3 for ESI.


Wow, you actually succeeded to get Squid3 to compile? ;-)

Chris

--
Simplistix - Content Management, Zope & Python Consulting
   - http://www.simplistix.co.uk

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



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

2007-05-22 Thread Jim Fulton


On May 22, 2007, at 9:20 AM, Martijn Faassen wrote:
...
I was rather annoyed at the whole situation. I switched to a hand- 
compiled python right away.


Better late than never. :)

Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



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



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

2007-05-22 Thread Marius Gedminas
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.)

>  - 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.

>  - 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?

Marius Gedminas
-- 
If you sat a monkey down in front of a keyboard, the first thing typed would be
a unix command.
-- Bill Lye


signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



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

2007-05-21 Thread Brian Sutherland
On Mon, May 21, 2007 at 04:44:41PM +0200, Reinoud van Leeuwen wrote:
> 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. 

You're not alone:)

I too much prefer to use system packages as much as possible to install
software on production servers. There are quite a few reasons why things
like buildout just don't do it for me. Mostly it's because my
requirements are different from the people who want to use buildout.

But then, I like eggs a lot as well, because the changes they are
causing in the way people develop in python is making life easier for
system packagers :)

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



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

2007-05-21 Thread Fred Drake

On 5/21/07, Reinoud van Leeuwen <[EMAIL PROTECTED]> 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.


That's understandable.  I don't think developers want to have extra
trees all over the place so much as they want one they can rely on.
The system Pythons generally aren't that, since various extra software
gets installed there.  It may also be built with different settings
for things like Unicode character size.

We've found it invaluable to have a separate "clean" Python that
doesn't have additional packages installed into it (ever), and then
our applications can provide what they need without polluting other
applications.  We can know what options the Python was built with.  It
also won't be affected by system updates.

Once we have such a clean Python, we can share it across however many
applications have need of it.


 -Fred

--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



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

2007-05-21 Thread Reinoud van Leeuwen
On Mon, May 21, 2007 at 10:39:22AM -0400, Fred Drake wrote:
> On 5/21/07, Gary Poster <[EMAIL PROTECTED]> wrote:
> >I then
> >feel comfortable sharing the dev Python across builds because I know
> >it is clean.
> 
> The stuff that gets installed in the system Python's is usually not an
> issue for Zope applications (I've never had a Zope-related issue with
> those things), but I always use a clean Python just to be safe in case
> something odd gets added to the system Python.  Ubuntu and the various
> RedHat-derived systems (Fedora, CentOS) add enough to the system
> Python that I'd rather avoid them for applications regardless.

I think developers and system- or application maintainers have different 
viewpoints in this.

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. 


-- 
__
"Nothing is as subjective as reality"
Reinoud van Leeuwen[EMAIL PROTECTED]
http://www.xs4all.nl/~reinoud
__
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



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

2007-05-21 Thread Fred Drake

On 5/21/07, Gary Poster <[EMAIL PROTECTED]> wrote:

I then
feel comfortable sharing the dev Python across builds because I know
it is clean.


The stuff that gets installed in the system Python's is usually not an
issue for Zope applications (I've never had a Zope-related issue with
those things), but I always use a clean Python just to be safe in case
something odd gets added to the system Python.  Ubuntu and the various
RedHat-derived systems (Fedora, CentOS) add enough to the system
Python that I'd rather avoid them for applications regardless.


 -Fred

--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



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

2007-05-21 Thread Darryl Cousins
Hi,


On Mon, 2007-05-21 at 08:12 +0200, Christian Zagrodnick wrote:
> On 2007-05-21 07:39:57 +0200, "Martijn Pieters" <[EMAIL PROTECTED]> said:
> 
> [...]
> 
> > 
> > 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?
> 
> No. Use buildout. Nothing will be installed into the system Python, 
> everything will be wired correctly. Use buildout. :)
> 

I agree, buildout is exceptional. I use ~/.buildout/default.cfg to
direct all those zope eggs to a known directory, system python remains
clean.

Regards,
Darryl

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