Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
On Tue, 23 Jun 2009 16:15:12 +0200, Fabio Tranchitella wrote: Hello all! In the last couple of weeks Brian Sutherland, Matthias Klose and I worked together to improve the Zope packaging for Debian and Ubuntu. This e-mail summarizes the problems we faced, the decisions that have been taken and the changes that we will upload to experimental and unstable in the next weeks. Short summary = We switch from a monolithic Zope 3 package to individual packages for the libraries that are part of the ZTK (Zope Toolkit). Zope instance management tools are not supported anymore, as we suggest the use of WSGI. We also drop support for Zope 2 and Plone in Debian and Ubuntu, asking for the removal of the packages from the distribution. I am certainly one person that did use the Debian packages at the time when people first started to suggest against it. I dropped this habit when I needed to work most of the time with custom Zope and Plone versions that were too new or too rare to be in Debian yet. But I'm still using Debian's python2.4 right now to bootstrap my buildouts. The main problem for Zope2 is that the current stable upstream branch (2.12) still requires pthon2.4. This is not acceptable in Debian and Ubuntu, and Zope 2 is right now the only stopper for the removal of python2.4 from both Debian and Ubuntu. What's the reason for the removal of python2.4? Is there a technological reason, or is this a policy decision? Don't forget that Plone users, who are also the biggest consumer group of Zope / ZTK, still will be users of 2.4 for a while. The unified installer is not the only installation method used for Plone, in fact many users and the majority of deployments use python + buildout. These users will need to read documentation and do installation to be able to bootstrap their buildout, which is not exactly a reason for them to choose Debian / Ubuntu in this case. -- Balazs Ree ___ 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] Hg mirror available
On Thu, 18 Jun 2009 14:28:13 -0300, Sidnei da Silva wrote: Hi Wolfgang, On Thu, Jun 18, 2009 at 7:31 AM, Wolfgang Schnerringw...@gocept.com wrote: * Sebastien Douche sdou...@gmail.com [2009-06-18 01:34]: This is a first attempt to build an Mercurial mirror : http://hg.zope.mirrors.securactive.org/ How did you convert the repository? I'm asking because I noticed that basically all SVN-DVCS conversion tools (hg convert, git-svn, bzr svn-import, svn2bzr, svn-fast-export.py, svn-all-fast-export.cpp) do not convert the history properly, more precisely, history that happened on branches is lost: 1. import /trunk/foo.txt 2. branch /trunk to /branches/mybranch 3. edit /mybranch/foo.txt 4. merge /mybranch to /trunk If you now ask svn for the history of /trunk/foo.txt (say with 'svn log'), you see both steps 3 and 4. After conversion to a DVCS with one of the above mentioned tools, you only see step 4, while step 3 never happened in the DVCS repository. I think that's unacceptable, most importantly because all commit messages that happened on branches are lost that way. Does somebody here know something about this phenomenon, by any chance? Am I missing something? Here's some context about this from one of the Bazaar developers, John Arbash Meinel. Hopefully that will solve some of your questions? In pretty much all dvcs merging a content exactly back to trunk does not generate a change message when doing bzr log foo.txt. I'm not really sure what he means by edit and then merge without a commit inbetween. So I'm assuming there is one. Now, what really matters is whether or not *Subversion* recorded 4 correctly, such that it can actually see that it was a merge from 3. My understanding is that before svn 1.5 that isn't possible. So you are left with trying to infer that sort of thing from the history. Which would be possible, but probably expensive. I'm pretty sure SVN represents (4) as not a *merge* but as an indentical commit. I don't have a great answer there. Though the fact that Wolfgang says svn shows both... I suppose because svn log shows everything across all branches? I'm somewhat confused here. According to my understanding: - all DVCS shows, if a merge is done, the changesets that origin from the merged branch. (this is the normal operation) - afaik svn does _not_ show this, what's more, it does not store any metadata about the merges or changesets involved. When doing the merge you really select a diff of the branch by specifying which changesets you want to include back in trunk. This is why it's so important with svn to note in the commit message, which revisions from which branch you merged. Otherwise you would not know at all what has been merged. So although, DVCS could represent the information about the merged changesets, this information will not be imported from SVN, simply, because the information is not represented in SVN. I'd like to add that I'm not using Hg, I am only using bazaar and svn, and I'm talking from what I experienced in practice with working on various svn repos and bzr. It's possible that newer svn does try to attack this problem by storing more metadata with the merges, which then would make sense to be considered at a DVCS import, but I believe that in the vast majority of svn repositories that you would consider importing, this information would not be there anyway, due to the fact that they are product of the older svn version. -- Balazs Ree ___ 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] zc.buildout broken
On Fri, 24 Apr 2009 13:10:30 +0200, Marius Gedminas wrote: On Fri, Apr 24, 2009 at 05:56:45AM +0200, Roger Ineichen wrote: Hi everybody Ran 367 tests with 50 failures and 1 errors in 8 minutes 14.891 seconds. The latest trunk of zc.buildout is completly broken. At least on windows. Can someone check this on linux? It is always interesting to see the failures, but attaching large log files to emails is not very polite. True for large files, but a traceback is not that large _imo_. Depends on your connection of course. Also, we are on a development list, so if somewhere, then here tracebacks are on topic. Solution: use a pastebin. I disagree: pastebin is good for linking from irc, but when I come back to the archive I would like to see the details even when the pastebin entry is gone. -- Balazs Ree ___ 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.testing.doctest] a nasty surprise
On Thu, 10 Apr 2008 11:50:35 -0400, Benji York wrote: Dieter Maurer wrote: As the community (apparently) strongly favors doctest over unittest, I wrote my first test based on zope.testing.doctest. And promptly, I was badly surprised In order to analyse a difficult problem, I added from dm.pdb import zpdb; zpdb.set_trace() in the doctest (dm.pdb.zpdb is my Zope aware PDB extension) The standard PDB works fine. I'm sure you're extended version can be tweaked to as well. I have similar issues with ipdb. - similar in sense that I cannot use it when running from doctests. ipdb is a lightweight component that enables entering ipython when import ipdb; ipdb.set_trace() is called. Those of you that use ipython and also develop with doctests a lot, will understand why it would be a nice to have also from doctests. In case of ipdb I had no parameters problem like Dieter encountered with zpdb, however I observed that the doctest runner needs to redirect input and output while running tests, which are specifically routed back to stdin and stdout while pdb.set_trace is entered, to enable interactivity. This is done by monkeypatching pdb if I remember well. But the same does not happen with ipdb, of course. So, my conclusion is that while doctests work well with the standard pdb, any alternate debugger must be supported explicitely (by changing the doctest code). As with ipdb, this may be the case with zpdb as well. Best wishes -- Balazs Ree ___ 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: running unit tests for Zope 2.8
Hi Geoff, On Mon, 13 Mar 2006 18:04:14 -0500, Geoff Davis wrote: bin/zopectl test --dir=/opt/Zope-2.8/lib/python/Products/SiteAccess/tests/ which yields the following: Running tests via: /usr/local/bin/python /opt/Zope-2.8/bin/test.py -v --config-file /home/zope/zopefix/etc/zope.conf --libdir Products --dir=/opt/Zope-2.8/lib/python/Products/SiteAccess/tests/ Running unit tests at level 1 Running unit tests from /opt/Zope-2.8/lib/python/Products/SiteAccess/tests Parsing /home/zope/zopefix/etc/zope.conf -- Ran 0 tests in 0.000s In my experience the --libdir must point to the *product* root and never to the test dir itself. It seems that the runner iterates through the test, ftest dirs under this root and in your case it finds none (since you are already inside it). So I would use bin/zopectl test --libdir=/opt/Zope-2.8/lib/python/Products/SiteAccess If I would want to run test from a specific file only, I would add the filename filter to the end like bin/zopectl test --libdir=/opt/Zope-2.8/lib/python/Products/SiteAccess \ Products/SiteAccess/tests/test_one.py and so on... -- Balazs Ree jabber + email: [EMAIL PROTECTED] ICQ: 75955071 AIM + skype: reebalazs ___ 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: [Proposal] Drop Mount.py from ZODB 3.5
Thu, 02 Jun 2005 19:38:02 -0400 Tim Peters wrote: We'd like to continue getting non-ZODB code out of the ZODB project, so would like to drop Mount.py from ZODB 3.5. Are any of zodb-dev's standalone ZODB users making use of Mount.py? I would be surprised by that too, since Mount.py relies on other code (like Acquisition) that's already been removed from the ZODB 3.3 and 3.4 lines. I've been surprised before, though ... Although this is not strictly an answer to the original question, I would take to opportunity to react and in the end ask for your opinion. I am asking this because I yet do not see entirely clear in the question of mounting; however, as you will see below, I could achieve my goal in a way. First, according to how much I see of it you are right that Mount.py does not belong to ZODB, and I personally would not even consider using this code for a standalone ZODB app since there are cleaner solutions to be considered. But, as far as Zope is concerned, I have to admit of just having used this code in an app that is currently under development. And here is my use case: The application in question is a complete re-write of an already existing zope application. Migration of the old data to the new application is a key question. There are several backups of the old data at hand that are made by repozo and that can be converted into Data.fs format. The initial migration of the data starts with mounting one of this Data.fs files into the filesystem of the new product, and then migrating the content from it to the new portal. Furthermore, I made testcase base classes for unittest that support migration by using any of the Data.fs files. This way I can have a sequence of migration sources stored in a directory and use automated tests to either test the migration from all of these sources, or I can pick any of the sources, migrate them and run my acceptance tests on the migrated content that is getting formed in the new application. Needless to emphasize the enormeous advantage that I gain with this in the flow of the development, and concerning the success of the future sharp migration that will have to work like a charm on the live system. So far for the case. As for the implementation, since the name of the Data.fs and the mount point are coming from parameters, I could not use the new dbtab style mechanism since these parameters cannot be statically defined in the configuration files. So I decided to subclass the MountPoint class and created a product that mounts a given Data.fs readonly to the given mount point. Now I would like to pose a question to all of you. I am of course not worried if Mount.py is getting phased out completely, since I would be able to take over the code from it into my subclass. But according to my use case described above, am I on the right track with my implementation? Or (supposing that Mount.py disappears) what would be the canonical way of achieving what I want from within Zope? -- Bala'zs REE' jabber + email: [EMAIL PROTECTED] ICQ: 75955071 AIM: reebalazs ___ 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 )
