[Zope-dev] [Zope 2.12] Eggification of Zope 2 - pros and cons?
Hi, during the latest 'zope.publisher' thread on zope-dev I came up with the proposal to eggify the Zope core for the Zope 2.12 release. I would like to start a discussion about the pros and cons, risks and advantages of any eggification effort. Chris favors a 'big' Zope egg with some dependencies (like ZODB) stripped out. I would prefer a more broader approach. One of the reasons are company-internals modifications to the Zope core. Right now we maintain a more or less heavy modified version of Zope 2.8 in our repos (making Zope upgrades pretty hard). A better modularization would help us here. Another example: the Plone people maintained a Zope 2.10 branch with experimental ZODB blob support. With an eggified version of ZODB you could easily switch the eggs (easily spoken). So before promoting the eggification as an ultimate goal, let's discuss what we really need and want. A complete eggification just for the sake of eggs is possibly not the goal :-) Andreas pgppXfc9cvnRV.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
Andreas Jung wrote: during the latest 'zope.publisher' thread on zope-dev I came up with the proposal to eggify the Zope core for the Zope 2.12 release. I would like to start a discussion about the pros and cons, risks and advantages of any eggification effort. Chris favors a 'big' Zope egg with some dependencies (like ZODB) stripped out. I have pretty much done this already. [1] defines an egg called 'Zope2'. All the Zope 3 eggs are dependencies, as are a few "non-core" packages such as ExtensionClass, Acquisition, etc. (which are already eggified and available on PyPI). I also started a branch of the Plone egg back then to see if it can be modified to install Zope 2 completely as a dependency. See [2]. I would prefer a more broader approach. One of the reasons are company-internals modifications to the Zope core. Right now we maintain a more or less heavy modified version of Zope 2.8 in our repos (making Zope upgrades pretty hard). A better modularization would help us here. Another example: the Plone people maintained a Zope 2.10 branch with experimental ZODB blob support. With an eggified version of ZODB you could easily switch the eggs (easily spoken). I feel indifferent to this in general, so feel free to split away more stuff from my 'Zope2' egg. So before promoting the eggification as an ultimate goal, let's discuss what we really need and want. A complete eggification just for the sake of eggs is possibly not the goal :-) [1] http://svn.zope.org/Zope2.buildout [2] http://svn.plone.org/svn/plone/dist/Plone/branches/philikon-buildoutify ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Sun Mar 23 12:00:00 2008 UTC to Mon Mar 24 12:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sun Mar 23 21:53:19 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009295.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sun Mar 23 21:54:49 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009296.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sun Mar 23 21:56:19 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009297.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sun Mar 23 21:57:49 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009298.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sun Mar 23 21:59:20 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-March/009299.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope 2.12] Eggification of Zope 2 - pros and cons?
On Mon, Mar 24, 2008 at 9:00 AM, Andreas Jung <[EMAIL PROTECTED]> wrote: > So before promoting the eggification as an ultimate goal, let's discuss > what we really need and want. A complete eggification just for the sake of > eggs is possibly not the goal :-) The goals as I see it is probably to simplify the buildouts, with less "parts" directories, and get everything in a consistent way, i.e. eggs. Also the eggification should simplify for repoze-style things, and as mentioned to replace some modules more easily. I think at least that as a start ZServer and ZPublisher should be separate eggs (if eggs at all, in fact) and all the Products.* stuff should probably be separate eggs as well. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
Philipp von Weitershausen wrote: Andreas Jung wrote: during the latest 'zope.publisher' thread on zope-dev I came up with the proposal to eggify the Zope core for the Zope 2.12 release. I would like to start a discussion about the pros and cons, risks and advantages of any eggification effort. Chris favors a 'big' Zope egg with some dependencies (like ZODB) stripped out. I have pretty much done this already. [1] defines an egg called 'Zope2'. All the Zope 3 eggs are dependencies, as are a few "non-core" packages such as ExtensionClass, Acquisition, etc. (which are already eggified and available on PyPI). That sounds like a good balance to me. We need to make sure that there's a single Zope egg that we can version-pin that'll always have a stable, working set up Zope 3 packages. Zope 3 is a whole farm-full of eggs, and version management can be tricky. Zope 3 has a KGS, of course, so maybe we can just use that. I also started a branch of the Plone egg back then to see if it can be modified to install Zope 2 completely as a dependency. See [2]. I'm pretty sure Plone 4 will want to do this. We (read: Hanno) is almost done eggifying all of Plone anyway. Note that the current "Plone" egg is not maintained and never quite worked out. Right now we use plone.recipe.plone to install Plone in a buildout, which version pegs all the plone.* eggs and friends (which are in PyPI), and then downloads a tarball of products that are added to the 'products' line in the generated zope.conf. We want to get rid of the latter, of course. I would prefer a more broader approach. One of the reasons are company-internals modifications to the Zope core. Right now we maintain a more or less heavy modified version of Zope 2.8 in our repos (making Zope upgrades pretty hard). A better modularization would help us here. Another example: the Plone people maintained a Zope 2.10 branch with experimental ZODB blob support. With an eggified version of ZODB you could easily switch the eggs (easily spoken). I feel indifferent to this in general, so feel free to split away more stuff from my 'Zope2' egg. Having Zope with a separate ZODB and a few other "big" pieces makes sense indeed. Having tons of small packages that no-one will ever re-use outside a large Zope just creates overhead and the potential for people to buildout themselves into version conflicts. So before promoting the eggification as an ultimate goal, let's discuss what we really need and want. A complete eggification just for the sake of eggs is possibly not the goal :-) [1] http://svn.zope.org/Zope2.buildout Yay for this. :) [2] http://svn.plone.org/svn/plone/dist/Plone/branches/philikon-buildoutify I'm not sure this is all that useful. For Plone 4, we're just going to have a number of plone.*, plone.app.* and Products.* (and a few others, like kss.*) eggs that we can put in a KGS or version pin in a single "Plone" egg. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
Previously Martin Aspeli wrote: > I'm not sure this is all that useful. For Plone 4, we're just going to > have a number of plone.*, plone.app.* and Products.* (and a few others, > like kss.*) eggs that we can put in a KGS or version pin in a single > "Plone" egg. For Plone 4 we may also collapse all the plone.app.* packages in a single package. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
Wichert Akkerman wrote: Previously Martin Aspeli wrote: I'm not sure this is all that useful. For Plone 4, we're just going to have a number of plone.*, plone.app.* and Products.* (and a few others, like kss.*) eggs that we can put in a KGS or version pin in a single "Plone" egg. For Plone 4 we may also collapse all the plone.app.* packages in a single package. +0.5 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sendmail grantma-retryfixes branch review
Hi! Just done edits you suggested. Some Unit tests still to be written. Won't be doing one for that /1000 as tehre are more important things to check like exception functionality. On Wed, 2008-03-19 at 23:32 +0200, Marius Gedminas wrote: > There are two checkins on the branch. > > = > rev 84645 > = > http://svn.zope.org/zope.sendmail/branches/grantma-retryfixes/?rev=84645&view=rev > > Matthew, Subversion thinks the two PDF files you added are plain-text > (svn:eol-style is "native", and svn diff shows the actual contents of > the PDFs, which isn't very useful to human readers). I would suggest > > svn propdel svn:eol-style *.pdf > svn propset svn:mime-type application/pdf *.pdf > > Also, the Quue_*.pdf seems to have a typo in the file name. > > At first sight those diagrams look scary and complicated. I'd look into > ways to express their content in a text file with plain-text > explanations and ASCII-art diagrams. I am paid to write code, not spend hours messing with documentation tools. Scans of my pencil diagrams are all that I can do because of time constraints. Better than nothing. > Index: src/zope/sendmail/tests/test_mailer.py > > === > > --- src/zope/sendmail/tests/test_mailer.py (revision 84550) > > +++ src/zope/sendmail/tests/test_mailer.py (revision 84551) > > > > def sendmail(self, f, t, m): > > self.fromaddr = f > > self.toaddrs = t > > self.msgtext = m > > +if hasattr(self, '_exception'): > > +if self._exception and issubclass(self._exception, > > Exception): > > +if hasattr(self, '_exception_args') \ > > +and type(self._exception_args) is tuple: > > +raise > > self._exception(*self._exception_args) > > +else: > > +raise self._exception('Crazy Arguments > > WANTED!') > > That's a bit of an overkill. If you change the _exception_args default > value to () above, it would be perfectly fine to replace this lats bit > with > >if self._exception: >raise self._exception(*self._exception_args) > > It's the job of the Python interpreter to check the suitability of > _exception and _exception_args for the raise statement, you don't have > to do everything by hand. Left this as I can't get what you suggest to work - this is only test code. I think this is there because this stub is used in many places,and this saves gobs of repeated test code. Due to time I can't look any further into this. > > +def test_unlink(self): > > +self.thread.log = LoggerStub() # Clean log > > +self.filename = os.path.join(self.dir, 'message') > > +self.tmp_filename = os.path.join(self.dir, '.sending-message') > > +temp = open(self.filename, "w+b") > > +temp.write('X-Zope-From: [EMAIL PROTECTED]' > > + 'X-Zope-To: [EMAIL PROTECTED], [EMAIL PROTECTED]' > > + 'Header: value\n\nBody\n') > > +temp.close() > > +self.md.files.append(self.filename) > > +os.link(self.filename, self.tmp_filename) > > Is os.link available on Windows? Don't think it is natively but they may have an abortion/aberrative thing to POSIXise the API! > > Index: src/zope/sendmail/delivery.py > > === > > --- src/zope/sendmail/delivery.py (revision 84550) > > +++ src/zope/sendmail/delivery.py (revision 84551) > ... > > +def _unlinkFile(self, filename): > > +"""Unlink the message file """ > > +try: > > +os.unlink(filename) > > +except OSError, e: > > +if e.errno == 2: # file does not exist > > +# someone else unlinked the file; oh well > > +pass > > +else: > > +# something bad happend, log it > > +raise > > I've seen this function before. Can you merge all the copies into a > global function, say, called safe_delete()? > You probably have seen this in another part of delivery.py that is very similar? Around os.link etc I have taken out all the exatly common code to that above if read delivery.py closely. > > +def _queueRetryWait(self, tmp_filename, forever): > > +"""Implements Retry Wait if there is an SMTP Connection > > + Failure or error 4xx due to machine load etc > > Blank line after the first one, then no extra indentation. > > > +""" > > +# Clean up by unlinking lock link > > +self._unlinkFile(tmp_filename) > > +# Wait specified retry interval in stages of self.interval > > +count = self.retry_interval > > +while(count > 0 and not self.__stopped): > > +if forever: >
[Zope-dev] Re: [Checkins] SVN: gocept.bsquare/branches/pcardune-setup/src/ add ignores
Paul Carduner wrote: Log message for revision 84912: add ignores Property changes on: gocept.bsquare/branches/pcardune-setup/src ___ Name: svn:ignore + gocept.bsquare.egg-info I think people generally treat .egg-info directories like .pyc files, they add an entry to their ~/.subversion/config "global-ignores" (at least I do ). No need to change this one, but much like ignoring .pycs, it'll save you a bunch of svn:ignore entries. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: gocept.bsquare/branches/pcardune-setup/src/ add ignores
Previously Benji York wrote: > I think people generally treat .egg-info directories like .pyc files, > they add an entry to their ~/.subversion/config "global-ignores" (at > least I do ). If you have custom entry points or local plugin you need to handle .egg-info differently. > No need to change this one, but much like ignoring .pycs, it'll save you > a bunch of svn:ignore entries. Unfortunately svn status ignores global-ignores, which for me is enough reason to use svn:ignore properties everywhere. I find svn status to be extremely useful when checking if you have not forgotten to commit something, which happened to me more than once too often. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: gocept.bsquare/branches/pcardune-setup/src/ add ignores
Wichert Akkerman wrote: Previously Benji York wrote: I think people generally treat .egg-info directories like .pyc files, they add an entry to their ~/.subversion/config "global-ignores" (at least I do ). If you have custom entry points or local plugin you need to handle .egg-info differently. I didn't understand that, but I wouldn't worry much about that. :) No need to change this one, but much like ignoring .pycs, it'll save you a bunch of svn:ignore entries. Unfortunately svn status ignores global-ignores That's not been my experience. Like you, I run "svn st" so often my "svnt" keys are almost worn out, but it ignores .pyc files just fine (and everything else in my global ignores). -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )