Re: [Zope-dev] New release of zope.interface
On 12/23/09 8:03 AM, Marius Gedminas wrote: On Wed, Dec 23, 2009 at 06:34:17AM +, Matthew Wilkes wrote: On 2009-12-23, at 0624, Marius Gedminas wrote: Releasing 3.8.5 now. …and it's broken. The testrunner directory isn't included in the tarball so egg_info fails. Gah, setuptools claims another victim! I must be using a version that doesn't support svn 1.6 working dirs. :( Can we please have a check for that in zest.releaser? A check for that? Seems sensible. I'm not getting around to do that (last two days in my current job; laptopless in the weekend) in the next few days, though. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zopetoolkit/trunk/ztk.cfg Include distribute, so we can use it in presence of the allow-picked-versions=false
On 12/15/09 11:49 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Log message for revision 106536: Include distribute, so we can use it in presence of the allow-picked-versions=false Changed: U zopetoolkit/trunk/ztk.cfg -=- Modified: zopetoolkit/trunk/ztk.cfg === --- zopetoolkit/trunk/ztk.cfg2009-12-15 15:33:38 UTC (rev 106535) +++ zopetoolkit/trunk/ztk.cfg2009-12-15 15:41:19 UTC (rev 106536) @@ -250,6 +250,7 @@ # Dependencies: ClientForm = 0.2.10 +distribute = 0.6.10 docutils = 0.5 infrae.subversion = 1.4.5 Jinja2 = 2.1.1 I'm not so sure that we want to push distribute into the ZTK dependencies: can you explain that more clearly? This is in the ztk.cfg, not the setup.py. So it isn't installed per se as a dependency. *If* you're using distribute and configured buildout not to pick versions by hand, this way at least you won't get an error. I suspect there's a setuptools=someversion somewhere in that ztk.cfg, too. Seems safe to me. If zc.buildout is in there, it ought to be 1.4.3, btw, to prevent distribute upgrades from recursing infinitely. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bootstrapping ZCA for Python 3.
On 12/15/09 2:21 PM, Marius Gedminas wrote: If I weren't extremely hungry and starving, I'd run the tests in the official fashion (bin/buildout bin/test) and see if I get the same failures. Be sure to look at DEVELOPERS.txt in the root (you need pythons without setuptools and you need to run with -c dev.cfg if memory serves me). Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] script to help with dependency cleanup
Hi, With all the dependency cleanup going on in the ZTK (and grok 1.1alpha) we wanted to try it out with our internal packages. So: removing unneeded dependencies from code. If you import from it, you must mention it as a dependency in your setup.py, so the setup.py needs cleaning up, too. To make that easier, I made z3c.dependencychecker that gives you a handy report on what to add or remove. Be careful and do some grepping of your own, too. And run the tests. And watch out for the obvious naming problems like PIL/Imaging and ZODB/persistence/btree. Anyway: 1.0 is just out: http://pypi.python.org/pypi/z3c.dependencychecker I've already fixed up grok's grokcore packages with this (and our intenral ones), so it is tested on a reasonable set of packages. Reinout ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Packing and GC versus packtime
On 2009-11-09, Christian Theune c...@gocept.com wrote: On 11/09/2009 02:47 PM, Jim Fulton wrote: On Mon, Nov 9, 2009 at 7:22 AM, Christian Theune c...@gocept.com wrote: I'm wondering: Scenario 1: I pack a storage to a time T and append X transactions after that Scenario 2: I append X transactions to a storage and then pack it to time T. Will those scenarios end up with the same result? I can imagine GC to get in the way, but I'm not sure about how it does its thing exactly. The question can also be phrased as: Are the operations pack and append transaction for storages commutative? Yes, as long as the pack time is before the time of the appended transactions. Right. Cool. Oh joy, oh joy! :) Sounds like you're working on your zeo sync tool? :-) Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Determining packages which are in the ZTK
On 2009-09-18, Tres Seaver tsea...@palladion.com wrote: - - Any package which doesn't have real narrative documentation checked into its 'docs' subdirectory, or a commitment from a maintainer to create such docs, should be on probation. This sounds like - It really has to be the docs/ subdir (which keeps it hidden from for instance omelette). - It should not be a doctest. /me wants to make sure Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On 2009-09-11, Sebastien Douche sdou...@gmail.com wrote: Caution with the actual workflow, 2 differences between SVN and Hg : - you cannot check out partial repository - external does not exist Missing externals has been a pain point for me. There are however buildout recipes that can pull in externals for you from buildout. infrae.subversion does it (and can turn the downloaded stuff into a development egg at the same time), Balasz Ree has a bzr recipe. I'm betting there's a mercurial one, also (and otherwise I'll build one if needed) :-) There remains a small pain point: you have to basically run buildout to update the externals in that way. A simple svn up/bzr up/etc doesn't update the externals... But there are of course lots of advantages to distributed systems that outweigh the small pain. So: missing externals are solveable if we all use buildout :-) Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] official release policy ZTK is still not changed
On 2009-09-11, Benji York be...@zope.com wrote: On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton j...@zope.com wrote: On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen faas...@startifact.com wrote: * I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools. The proposed change would make this tool simpler. zest.releaser's job would not become simpler. It currently grabs the version (with or without dev marker) from either version.txt (old projects or non-setup.py stuff) or the setup.py. Suddenly it is '0' instead of '1.2dev'. What's it going to suggest as new version? Yeah, it grabs the tags from subversion so it *can* make a decent guess. But you cannot easily register I want this to become 2.0 anymore. More importantly, it makes things simpler for people who don't use the tool. +1 -- reducing the number of tools necessary to (easily) accomplish a particular task is valuable. I'd rather do a bin/fullrelease (one step) instead of following a 7-step method to properly release a package. And setting the version to 0 only adds one more potential error point: where do you look up the next version? Someone might have forgotten to tag the previous release (if you look at tags) or might have forgotten to update the CHANGES.txt (if you look at that) or have not uploaded it to pypi (if you look at that). People aren't that good at repetitive tasks. Use a small tool like zest.releaser (or collective.releaser if you don't mind occasional 1.2-r1234 releases as that uses the setup.cfg for the dev marker). Use such a tool and you won't have to bash yourself or co-workers for - forgetting to tag a release. - forgetting to use 'register' in 'sdist upload register' so that the documentation on pypi isn't updated. - forgetting to remove a dev marker (or changing the 0). - Updating the changelog, preparing it for the next changes. Well, we might as well do away with buildout. Reducing the number of tools... Just do it by hand! Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] official release policy ZTK is still not changed
On 2009-09-11, Martijn Faassen faas...@startifact.com wrote: Jim Fulton wrote: but if it is, I propose to using 0 instead of the dev of the next version. Where I've used '0', I've found it to be less error prone. Ir also requires less effort because it means you never have to edit the version on the trunk. I'm -1 to using 0. -1 Reasons: * it breaks dependencies on development versions which have version requirements in it (see Wichert's comments on the original thread). Really important. When I add an external to a trunk/branch version of something as I need to fix/improve something, I immediately change the version requirement in the setup.py. What's better? Do a my.package 2.7 or leaving it at my.package = 2.5 and trusting your memory to change that afterwards? You'll surely see the my.package == 0 when releasing (as stuff breaks), which means more work as you have to look up version numbers again. Make it easy to do the right thing instead of making it more work, I'd say. The '0' means it is easier (human nature...) to just leave the version requirement in the setup.py alone as it is too much hassle. * I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools. In case the policy is changed, I'll of course fix up the tool. I'm still -1, though :-) This way it is much easier to help new people get up to speed in our community, maintain consistent practices, and people already in our community will also have an easier time keeping track of what's going on. A '0' version does little to help people pitching in with a bugfix. They'll have to figure out themselves what the version is supposed to be. If you pick the my.project/branches/reinout-fixthingy branch and the version is set to '0', you'll have to figure out what version of the branch is. A 2.8 bugfix branch? A feature brach off the trunk? The '0' seems especially unclear for branches. [I hope people who appreciate having such a policy will chip in here and say yes, I want a written-down policy, please so it isn't just me who is telling Jim this.] for i in range(20): print yes, I want a written-down policy, please Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] where is zc.zservertracelog 1.2.0?
On 2009-09-11, Gary Poster gary.pos...@gmail.com wrote:
Hi. pypi advertises http://pypi.python.org/pypi/zc.zservertracelog/1.2.0
but there is no download to be found! :-) Could whoever made the
release add the download?
Related to the recent 1.2dev or 0 discussion where zest.releaser was
mentioned: this is a great example where small inobtrusive tools like
zest.releaser and collective.releaser help a lot.
The tool won't forget to make the upload!
Don't make things unclear ('0' instead of '1.2dev') to save you one edit
action upon releasing as it is easier for doing a release by hand.
Especially if doing a release by hand means several unneeded manual edit
actions (updating changelog with release date and a new section, for instance)
that you wouldn't need by using a small tool.
Reinout
--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
Military engineers build missiles. Civil engineers build targets
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] official release policy ZTK is still not changed
On 2009-09-15, Tres Seaver tsea...@palladion.com wrote: If you are making releases without having the CHANGES.txt open in your browser, then you need to put down the keyboard and back away slowly, so that nobody gets hurt. Reviewing / correcting the changelog (and comparing it with a diff from the last release) should be a fundamental part of making a release. At the very minimum, you're supposed to update the release date in the changelog, right? Checking the changelog: yes, do that. And again, zest.releaser takes the make doing the right thing simple approach by providing a lasttagdiff command to show the diff of the current checkout with the last tag it can find in svn. For the common case, this helps a lot. And updating the release date? Yes, zest.releaser does that for you so that you never ever forget it. (And yes, it first shows you a diff and asks you to press yes so you do get to review it and you're constantly reminded about what's happening). I *like* the property of the 0 strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review. Seen from a different viewpoint, this also makes it an unappetizing yucky event. Human nature then quickly takes over and tries to find corners to cut. And human nature includes mistakes, so stuff is forgotten (like that forgotten upload to pypi we saw here on the mailinglist). Tres, is your preference something personal or is it something you'd like to see everyone adopt? In that case my zest.releaser would be quite high on your things-to-torture list :-) Which would sadden me a bit as my goals were: - make it easy to do the good thing (like an easy diff with the last tag) - make it painless and take the hassle out of it - get more good releases. The '0' would be something zest.releaser could code around, so it would defeat the purpose of making it harder. The loss of clarity would still be there. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] test_requires and test runners
I have several packages that have some extra dependencies for testing. There's tests_require in setup.py, but there's also extras_require where you can add a 'test'. The extras_require is what I use now. In buildout's [test] section, you simply do something like: [test] recipe = ... eggs = my.egg my.egg[test] With recent buildout versions, a 'my.other.egg[test]' in my.egg's 'test' extras_require is also picked up OK. But: I don't want to look in all my dependencies whether they have or haven't got a 'test' extras_require. The main problem surfaces when using a test-all runner like plone.recipe.alltests: you don't want to figure out for all those package's whether they have such a 'test' extras_require... So: any ideas on how to deal with this? Alternative setups? Use test_requires? Should test runners pick it up automagically? Is there something plone.recipe.alltests could do? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Product configuration in zope.app.wsgi
On 2009-08-22, Uli Fouquet u...@gnufix.de wrote: As it turned out product configurations are not set with zope.app.wsgi (contrary, for instance, to zope.app.server). [...snip...] Is there a special reason why that was not included in zope.app.wsgi? My question exactly. And this raises another question: if it wasn't included, is that because there is a better way of handling configuration? My goal is to have settings in buildout, outside the actual code that uses it. So I want to use buildout for setting mail hosts and standard email recipients, stuff like that. Using a template recipe to generate a file somewhere? Stuff it into the ini file that is used by paste? More ideas? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] testing everything
On 2009-08-18, Hanno Schlichting ha...@hannosch.eu wrote:
On Tue, Aug 18, 2009 at 4:07 PM, Reinout van Reesrein...@vanrees.org wrote:
Question: is there an existing recipe that does this? Main point is that I
don't want to specify the dependencies that are to be tested by hand, so that
seems to rule out z3c.recipe.compattest. But there's been so much talk about
testing everything in the last weeks that I thought it better to ask :-)
I wrote http://pypi.python.org/pypi/plone.recipe.alltests, which tries
to do something similar at least.
Ha! That works fine and we're going to use it.
I *did* get a bit scared of all the errors you get in zope.app.* packages.
But that's apparently a known problem (and something that can be suppressed by
the exclude parameter).
What do you think about adding defaults for the eggs and test-script
parameters? Defaulting them ${test:eggs} and bin/test is probably enough in
99% of the cases. If you're OK with that I'll try it in a branch.
Reinout
--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
Military engineers build missiles. Civil engineers build targets
___
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] testing everything
On 2009-08-19, Hanno Schlichting ha...@hannosch.eu wrote:
On Wed, Aug 19, 2009 at 10:40 AM, Reinout van Reesrein...@vanrees.org wrote:
I *did* get a bit scared of all the errors you get in zope.app.* packages.
But that's apparently a known problem (and something that can be suppressed
by the exclude parameter).
The main intent for the exclude argument is to exclude packages which
cannot be tested either from their shipped distribution or are not
zope.testing compatible like pytz, Paste, WebOb or similar.
If there's failures in zope.app these should be fixed ;)
Yep. There was a some discussion here about that (in a thread about running
all tests on the ZTK iirc) that the combination of tests was in a sad state.
jdriessen suggested that might be something to sort out partially at the
upcoming grok sprint.
What do you think about adding defaults for the eggs and test-script
parameters? Defaulting them ${test:eggs} and bin/test is probably enough in
99% of the cases. If you're OK with that I'll try it in a branch.
Reinout made a branch and these changes are soon available in a new release.
Yep, they're released. Thanks!
Reinout
--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
Military engineers build missiles. Civil engineers build targets
___
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] whitespace filtering corner case in doctest
On 2009-08-17, Marius Gedminas mar...@gedmin.as wrote: On Mon, Aug 17, 2009 at 02:46:46PM +, Reinout van Rees wrote: In some cases, importing readline can result in the escape code ^[[?1034h= to be send (8bit on). According to the gentoo bug report (liked from your blog post), this happens if your termcap/terminfo define smm/rmm codes (meta on/meta off). ... which I didn't do, at least not consiously. Just a pretty normal OSX installation. BTW, regarding your workaround: I'd suggest using TERM=3Ddummy instead of TERM=3Dlinux, as a safer choice. Not that it should matter much in practice. That'd be better, yes. I never do anything tweaking with TERM anyway, so I don't know the options/effects. jladage suggested to do the workaround in buildout, btw: add the following to the part that generates the bin/test script: environment-vars = TERM linux This escape code isn't visible, which leads to hard to find test errors, see http://reinout.vanrees.org/weblog/2009/07/16/invisible-test-diff.html Granted, it are basically corner cases. On the other hand, it does seem to cause problems now and then, according= to my googling. Would it be ok to add it to the whitespace normalization of doctests? Opinions? Well, it's not whitespace, really... My gut feeling is that this fixup doesn't belong in the core doctest code. Ok. If this happened in my project, I'd either 1) make sure I import readline at module level, before any tests are run This doesn't work, surprisingly. It *is* a corner case. It are tests where z3c.testsetup tests that it runs tests correctly. That's a lot of tests in one sentence, which means that the test output comes from separate python processes that run tests. So if I import readline in z3c.testsetup's tests, I still get the output from the test runners that are being tested. Sigh, difficult to explain, such a recusive testing thingy :-) or 2) add a renormalizer that removes the escape sequence for the test that triggers this And you'd do this per-project and not in core zope.testing, right? Fine. Uli already send me some example code, so I'll do that (and put the code snippet on my weblog so that google can find it). Perhaps it would be nice if doctest's differ escaped ASCII control characters? (You could do that too with a renormalizer.) Can we safely assume that a specific set of control characters needs to be escaped? It sounds a bit dangerous to me. Thanks! Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] testing everything
In many buildouts I have a [test-all] section. Just like [test], but then with more eggs (typically all the dependencies). That's too much work, so I'm looking for a recipe to handle that for me. My thoughts: - Subclass zc.recipe.testrunner in a new recipe. - Look for a [test] part in buildout and take the defaults there. - Examine the eggs in test:eggs and look up their setup.py dependencies. - Those dependencies, that's the new list of eggs that need testing. - Just a [test-all] with the new recipe should be enough to test all main dependencies. Question: is there an existing recipe that does this? Main point is that I don't want to specify the dependencies that are to be tested by hand, so that seems to rule out z3c.recipe.compattest. But there's been so much talk about testing everything in the last weeks that I thought it better to ask :-) Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] whitespace filtering corner case in doctest
In some cases, importing readline can result in the escape code ^[[?1034h to be send (8bit on). This escape code isn't visible, which leads to hard to find test errors, see http://reinout.vanrees.org/weblog/2009/07/16/invisible-test-diff.html Granted, it are basically corner cases. On the other hand, it does seem to cause problems now and then, according to my googling. Would it be ok to add it to the whitespace normalization of doctests? Opinions? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] test setup layer sorting
On 2009-07-13, Marius Gedminas mar...@gedmin.as wrote: On Mon, Jul 13, 2009 at 12:27:50PM +, Reinout van Rees wrote: I my test files, I had two separate zcml files (one registered a bit more than the other). So I ended up with two separate ZCMLLayer subclasses. And both did some grokking. So apparently the teardown of a ZCMLLayer subclass when going from one to the next isn't that clean. There *is* a warning in zope.testing that teardown isn't fully supported. Ah, that one. zope.testing supports test layers that muck up the global state irrepairably (by letting the layer's tearDown method raise NotImplementedError) and continues running the subsequent test layers in a fresh and squeaky-clean subprocess. Unfortunately, a separate process means separate coverage data tracking, and currently zope.testing doesn't support merging coverage data from several processes. Thanks a lot, now I finally understand the cause of the problem I've been seeing. It is OK to figure out *when* something goes wrong, but the *why* is more important. Thanks! Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] test setup layer sorting
On 2009-07-13, Marius Gedminas mar...@gedmin.as wrote: zope.testing supports test layers that muck up the global state irrepairably (by letting the layer's tearDown method raise NotImplementedError) and continues running the subsequent test layers in a fresh and squeaky-clean subprocess. Unfortunately, a separate process means separate coverage data tracking, and currently zope.testing doesn't support merging coverage data from several processes. Fortunately, the NotImplementedError in ZCMLLayer's tearDown is just a precaution, 99% of the time it is sufficient to run CleanUp.tearDown to get the global state restored to its pristine condition. You can indicate that it is safe by passing allow_teardown=3DTrue to ZCMLLayer's constructor. As a result: * the tests will run marginally faster (no subprocess overhead) * you will be able to use pdb in your tests (zope.testing disables pdb in a subprocess since it wants exclusive control over stdout) * you will be able to get accurate coverage tracing. Now, how you can convince z3c.testsetup to pass allow_teardown=3DTrue to the ZCMLLayer it constructs, I don't know. I've never used z3c.testsetup (although it sounds like an interesting library and I should check it out some day). z3c.testsetup is great as it cuts down on the amount of repeated test setup code. (iirc stuff like nose and py.test also try this). Uli (=z3c.testsetup author), what about changing z3c.testsetup's default in this regard? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] test setup layer sorting
zope/testing/testrunner/runner.py's order_by_bases() function orders layers by inheritance, basically. So if you've got a FunctionalTestLayer that inherits from some BasicTestLayer, the tests that use the basic test layer will be executed before the functional test layer ones. If there's no inheritance, the layers are sorted by name. Quite sane. Problem: I use grok. Which does some magic that probably throws off the code coverage reports. Quite some code appears untested, even though I *do* test it. The problem disappears if just import the python module first in some basic test before the grokking happened. I use z3c.testsetup: - My basic doctests end up on the zope.testing.testrunner.layer.UnitTests layer. - My functional doctests on the z3c.testsetup.functional.layer.DefaultZCMLLayer layer which inherits from zope.app.testing's ZCMLLayer. - zope.app.testing's ZCMLLayer does not inherit from anything, so also not from zope.testing's unittest layer. - 'zope' is alphabetically behind 'z3c.testsetup', so the functional layer is sorted in front of the basic unittest one. - So my grokked code appears untested. What's the best solution? Should zope.app.testing's ZCMLLayer inherit from zope.testing's UnitTests layer? Should z3c.testsetup do some inheriting of its own? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] test setup layer sorting
On 2009-07-13, Marius Gedminas mar...@gedmin.as wrote: Whatever grok does that interferes with coverage should be fixed. I did some more debugging. In the end it boils down to this: With z3c.testsetup, you can specify a zcml file at the top of your test file. z3c.testsetup creates a ZCMLLayer with that zcml file. I my test files, I had two separate zcml files (one registered a bit more than the other). So I ended up with two separate ZCMLLayer subclasses. And both did some grokking. So apparently the teardown of a ZCMLLayer subclass when going from one to the next isn't that clean. There *is* a warning in zope.testing that teardown isn't fully supported. Personally, I'm not sure where the exact problem is. Grok does decorator-like wrapping (should not throw off the coverage testing) and plain component architecture registration (should not throw off the coverage testing either). Tearing down a component architecture layer? Code coverage problems don't seem too common. Probably an interaction between two problems. How I solved it: just use one zcml layer in z3c.testsetup and do some extra grokking in the test itself instead of in the second zcml file. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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.async: cron replacement?
On 2009-06-24, Gary Poster gary.pos...@gmail.com wrote: zc.async can be used to do cron-like activities by starting a job, to be performed after a certain time, that has a callback that reschedules another job when desired. This has the advantage over cron-like behavior because it does not reschedule until the first job is done. Well, for a task that runs a couple of seconds once a day or once a week... My first thought was if something goes wrong, the chain is broken and no new jobs will be scheduled anymore. From the documentation, it seems zc.async is pretty robust so this is probably not something I have to worry about. I'd put a short paragraph in the readme that this is how you can do cron jobs. Helps with the google for zope cron, too :-) Other zc.async competitors have cron implemented more directly, but I found it to be very easy and flexible to do what I wanted using the zc.async approach. Thanks for the info. I'll see if I can get a basic cron-with-pack setup in one instance running. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] zc.async: cron replacement?
Hi all, In messages like http://www.mail-archive.com/zope3-...@zope.org/msg05964.html, zc.async is mentioned as the solution for cron-like functionality in zope. Effectively you would not need zope2's clockserver. Reading zc.async's docs, I cannot find how to do a given task regularly. For example a weekly pack. Or a daily call of one method that archives older items. That sort of stuff. Many things can be handled by cronjobs, but you tend to get a lot of them. And you don't want to embed the password everywhere. Anyway: I cannot find the word cron anywhere in the zc.async source. Or repetitive or regular. Is zc.async not intended for this kind of usage? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] REQUEST vs. request
On 2009-06-16, Patrick Gerken do3cc...@googlemail.com wrote: A testcase in my code fails, and after a lot of digging, I am finding that the reason are wrong results from the catalog. The catalog returns bad results because he caches the results in the request. My test consists of a number of steps, for multiple times I do a getMultiAdapter, always with fresh TestRequests. Still it seems, that the catalog always use some other, rotten REQUEST. I've had the same problem in some test. If I remember correctly it had to do with the path index. What I did in the end in my doctest was to delete the REQUEST attribute that the index used for caching. It looks a bit weird to have a delete_interfering_request_to_fix_test() all the time, but it worked. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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 sprinting at EP
On 2009-06-11, Christian Theune c...@gocept.com wrote: I see we have a grok sprint working towards grok 1.0 at the EP. For those that haven't seen it: http://reinout.vanrees.org/weblog/2009/06/09/grok-europython-sprint.html I'd like to spend my sprinting time on ZTK issues which currently include: - Organisational stuff (Bug tracking, things listed in steering group topic list) - Further improvements to package dependencies If anybody wants to join me, I've added the sprint to the EP wiki: http://wiki.europython.eu/Sprints Great! Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] [Checkins] SVN: zope.app.http/trunk/ - Replaced thedependency on zope.deprecation with BBB imports
On 2009-05-26, Roger Ineichen d...@projekt01.ch wrote: Some people think it's better to have a nice clean log then deprecation warnings on server startup. I still don't understand the reason if there is any. Probably others can explain why we skip the deprecation warnings which is a hugh win for migration tasks. Main reason: often you get buried in deprecation warnings which then drown out potentially more important warnings. When migrating: yes, such deprecation warnings are handy. But in 99% of the cases you'll just be *using* the various libraries and you still get a load of warnings. Complaints/questions about the huge list of deprecation warnings in earlier plone versions were a regular occurrence on the mailinglists. So: yes, there's a reason. Perhaps not the best one, but still. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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 2009-04-24, Reinout van Rees rein...@vanrees.org wrote: I have 9 failures and 1 error on OSX. Most of them have to do with there not being a setuptools egg, but a setuptools develop egg, for example: Reminded by the talk about posting tracebacks: here's mine :-) http://reinout.vanrees.org/download/buildout_2009-04-24.txt Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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 2009-04-24, Roger Ineichen d...@projekt01.ch wrote:
I think there are different things wrong. The first
error looks like a difference in linux and windows
output:
--
File d:\eggdev\source\zc\zc.buildout\trunk\src\zc\buildout\buildout.txt,
line 55, in buildout.txt
Failed example:
ls(sample_buildout, 'eggs')
Expected:
setuptools.egg
- zc.buildout.egg
Got:
- setuptools.egg-link
- zc.buildout.egg
Actually, this very same difference is what I'm getting on OSX. So there's
some deeper problem here. I get it with both python 2.4 and 2.5, btw.
Perhaps the way setuptools is installed in our python environment? When
testing with python2.4, my bin/buildout looks like this:
-
#!/opt/local/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python
import sys
sys.path[0:0] = [
'/Users/reinout/svn/zc.buildout/src',
'/Users/reinout/.buildout/eggs/zope.testing-3.7.3-py2.4.egg',
'/Users/reinout/.buildout/eggs/zope.interface-3.5.1-py2.4-macosx-10.5-i386.egg',
'/opt/local/lib/python2.4/site-packages',
]
import zc.buildout.buildout
if __name__ == '__main__':
zc.buildout.buildout.main()
--
And my bin/test:
--
#!/opt/local/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python
import sys
sys.path[0:0] = [
'/Users/reinout/svn/zc.buildout/src',
'/Users/reinout/svn/zc.buildout/zc.recipe.egg_/src',
'/Users/reinout/.buildout/eggs/zope.testing-3.7.3-py2.4.egg',
'/Users/reinout/.buildout/eggs/zope.interface-3.5.1-py2.4-macosx-10.5-i386.egg',
'/opt/local/lib/python2.4/site-packages',
]
import os
sys.argv[0] = os.path.abspath(sys.argv[0])
os.chdir('/Users/reinout/svn/zc.buildout/parts/test')
import zope.testing.testrunner
if __name__ == '__main__':
zope.testing.testrunner.run([
'--test-path', '/Users/reinout/svn/zc.buildout/src',
'--test-path', '/Users/reinout/svn/zc.buildout/zc.recipe.egg_/src',
])
-
Does that give a hint?
Reinout
--
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
Military engineers build missiles. Civil engineers build targets
___
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.recipe.cmmi shared builds
On 2009-03-24, Wolfgang Schnerring w...@gocept.com wrote: I'd like to extend zc.recipe.cmmi to support shared build directories. Use case example: we use lxml in a lot of our projects, which currently means having to build libxml and libxslt over and over again, since the buildout needs to be standalone and thus can't depend on them being installed on the system. But while that's a necessity for deployment, it's really annoying for development. I added a feature to http://pypi.python.org/pypi/z3c.recipe.staticlxml last week that skips the expensive compilation step if there's already an lxml egg. I could do that by using a couple of assumptions that were build into the recipe. So if you need the shared build directory just for lxml, this could save you some work. The recipe uses zc.recipe.cmmi, though, if I remember correctly. So your approach could fix it at the source instead of my one-recipe-only solution :-) Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] Single Sign On
Shane Hathaway schreef: * The SSO process should be very similar to an ordinary cookie-based login process. I don't want the user to have to enter their username on one form and their password on another, but that's the standard OpenID process. * This will be implemented in Zope 3. We are considering OpenID, Shibboleth, CAS, and any other mature system that others might suggest. Shibboleth seems like the most obvious fit, but it's nowhere near as popular as OpenID. I haven't yet looked at CAS in detail. Alternatively, I have wondered if we actually need full-blown SSO; perhaps a carefully constructed domain-wide cookie would do the trick. In the two cases where I've been involved in SSO, both times there was some apache module that could handle the actual SSO-part. The result from zope's viewpoint was either a special http header or a special cookie. Working from that header (special_user=username_you_want) or cookie with similar contents is easy with zope2/plone's PAS and thus also zope2's authentication system which is mostly similar. You can look at http://svn.plone.org/svn/collective/PASPlugins/apachepas/ for some copy/paste code. So: easiest way is to let some trusted apache plugin handle the hard part and then laugh all the way to the bank with some 100-line authentication plugin. Reinout -- Reinout van Rees http://reinout.vanrees.org/ ___ 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: straighting out the SQLAlchemy integration mess
Brian Sutherland schreef: Unfortunately, it doesn't seem an option, right now, to avoid using ZCML to setup database connections. So I'm not sure how you want to implement your ideas? Something we did for an LDAP connection that needed the same kind of server-dependent config: put an ldapconfig.py file in zope's etc/ dir and load that if available from the code that configures ldap. Not the best of solutions, probably, but it worked. What I wanted to say: this *is* a way to avoid using zcml! Reinout -- Reinout van Rees Blog: http://vanrees.org/weblog/ [EMAIL PROTECTED] Work: http://zestsoftware.nl/ http://vanrees.org Video: http://reinout.blip.tv/ ___ 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: What happened to the infrae.subversion and py eggs?
Wichert Akkerman schreef: Previously Reinout van Rees wrote: Tres Seaver schreef: Daniel Nouri wrote: 1.0dev-r27844 seems to be gone from PyPI. Such a version should *never* have been released to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world). I've made it a habit *not* to enable the option in setup.cfg that adds those svn revision numbers to the version. It is enabled by default in all/most of the ZopeSkel-generated packages that I use. I recently started adding that option again for some of my projects. For a few frequently updated sites I do a lot of updates installs without making full releases and it is extremely convenient to be able to see which exact revision number I'm currently using. Those are probably private and not on pypi, I guess? Or do you do that for a few pypi'ed packages, too? I basically don't trust myself enough to enable it for public packages :-) Reinout -- Reinout van Rees Blog: http://vanrees.org/weblog/ [EMAIL PROTECTED] Work: http://zestsoftware.nl/ http://vanrees.org Video: http://reinout.blip.tv/ ___ 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: What happened to the infrae.subversion and py eggs?
Tres Seaver schreef: Daniel Nouri wrote: 1.0dev-r27844 seems to be gone from PyPI. Such a version should *never* have been released to PyPI (any egg / source dist with an SVN revision number in its filename is *not* suitable for sharing with the wider world). I've made it a habit *not* to enable the option in setup.cfg that adds those svn revision numbers to the version. It is enabled by default in all/most of the ZopeSkel-generated packages that I use. That single change forces me to maintain a proper version number in the setup.py (0.9 dev 3 for development versions). That is the spot where you make a change anyway when doing a release. It is wy too easy to forget to remove the subversion revision option from setup.cfg (and having to enable it again after the release). Somehow it helps :-) Reinout -- Reinout van Rees Blog: http://vanrees.org/weblog/ [EMAIL PROTECTED] Work: http://zestsoftware.nl/ http://vanrees.org Video: http://reinout.blip.tv/ ___ 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: anon http svn access status?
Christian Theune wrote: Hi, the repository is now mirrored at this location: http://svn.zope.de/zope.org/ It syncs to the master repository every 5 minutes. Hurray, thanks a lot. Reinout -- Reinout van Rees - Programmer at http://zestsoftware.nl/ http://vanrees.org/weblog/ mailto:[EMAIL PROTECTED] White space, the opposite of black hole? -- Joris slob ___ 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: anon http svn access status?
On May 3, 8:40 am, Christian Theune [EMAIL PROTECTED] wrote: What makes you feel the zope.org server moved to 1.4? It doesn't support the replay command, so it doesn't look updated. Sorry, I must have drawn the wrong conclusion when I did some googling to see whether it had all been done already. Jim mentioned (quite a number of weeks ago) that svn would be down a short time for for an upgrade, that probably also falsly registered as upgade to 1.4 to me ;-) Reinout ___ 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: anon http svn access status?
On Mar 2, 12:01 pm, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Reinout van Rees wrote: On Mar 1, 2:50 am, Christian Theune [EMAIL PROTECTED] wrote: the DZUG is working on a read-only mirror that will be accessible via anonymous HTTP. It will likely be available shortly after the upcoming Subversion ugprade. Great news. One question: you mention the upcoming subversion upgrade and Jim mentioned a zope.org subversion upgrade. Is that the same upgrade you're talking about? So: is dzug arranging the read-only http mirror via zope.org or will it be at dzug.org? I'm guessing that the upgrade ofsvn.zope.org to subversion 1.4 will allow them to use svnsync to sync it to their own repository, outside of zope.org. Resurrecting an old thread :-) From what I figured from irc and some dzug.org google searching, the zope svn has now apparently been moved to 1.4. Christian, do you know what the status of the dzug mirror is? Reinout ___ 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: anon http svn access status?
On Mar 1, 2:50 am, Christian Theune [EMAIL PROTECTED] wrote: the DZUG is working on a read-only mirror that will be accessible via anonymous HTTP. It will likely be available shortly after the upcoming Subversion ugprade. Great news. One question: you mention the upcoming subversion upgrade and Jim mentioned a zope.org subversion upgrade. Is that the same upgrade you're talking about? So: is dzug arranging the read-only http mirror via zope.org or will it be at dzug.org? Reinout ___ 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] anon http svn access status?
Hi all, This morning I proposed on the plone.dev list to create a anon http mirror of svn.zope.org and to include links to that in the plone bundles. It is one of those perpetual proposals that turn up from time to time buried at the tail end of mailinglist threads. It would be nice if So I started a separate thread for it to get it discussed for real :-) Wiggy rightfully suggested I'd ask it here first, as it would be something that's best handled by svn.zope.org itself. I searched the mailinglist a bit and it seemed that write access using https is out of the question policy-wise, but that http anonymous access could happen. plone's svn has a read-only mirror at google code now, perhaps that's a good option for svn.zope.org, too? So: will anon http svn access happen? Reinout -- Reinout van Rees r.van.rees @ zestsoftware.nl http://vanrees.org/weblog/ http://zestsoftware.nl/ Military engineers build missiles. Civil engineers build targets. ___ 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: anon http svn access status?
Wichert Akkerman wrote: Previously Reinout van Rees wrote: plone's svn has a read-only mirror at google code now, perhaps that's a good option for svn.zope.org, too? That's not true at this moment. Right now we have svn-mirror.plone.org, which is hosted on the other plone.org server (we have two at the moment). We will also create a mirror at code.google.com next week. The mirrors are synced every 10 minutes using svnsync. Ah, ok. Mixed up a few mail messages in my head :-) Reinout -- Reinout van Rees r.van.rees @ zestsoftware.nl http://vanrees.org/weblog/ http://zestsoftware.nl/ Military engineers build missiles. Civil engineers build targets. ___ 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: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Martin Aspeli wrote: Unless Utopia really exists I think developers all have their own thoughts about setting up their development environment. Maybe. Except if we (the plone core developers) use ploneout then we are all using the same environment, and we duplicate less work. Same reasoning I had with instancemanager, so I agree. I explicitly made it reasonable easy to set some defaults to have it fit everyone's favourite way of ordering his stuff. Instance in ~/instances/philips by default, but Jean-Paul can set it to a default of ~/Sites/philips, for instance. But even with that level of adaptability-to-individual-taste, not everyone uses it for our zest projects. Rocky not, iirc, for instance. Neither nouri. So: it duplicates less work and we all would have the same environment are great reasons, but they don't always work :-) Again most developers are pretty demanding about setting up a development environment. Here at Zest most of us are comfortable with instancemanager. That's possibly something to do with the fact that you wrote it :) I'm not saying it isn't great, and there's no reason why people shouldn't use it if it works for them. But zc.buildout predates it, seems to be adopted more and more in the Zope 3 world (including people like grok), seems more flexible to me... and I like it. :) Well, predates it... Theoretically, yes. But in practice it was some internal zope corp tool. I only first noticed it when Jim gave a talk about the new improved egg-using version at 2006's Europython. Later that same day I gave a lightning talk about instancemanager. So at least to my viewpoint, it has the same age. http://vanrees.org/weblog/archive/2006/07/04/jim-fulton-zc-buildout http://vanrees.org/weblog/archive/2006/07/04/europython-lightning-talks Ultimately, though, it doesn't really matter what people use. However, at the upcoming Amsterdam sprint, I intend to ask people to do this: $ svn co https://svn.plone.org/svn/plone/ploneout/trunk plone3 $ cd plone3 $ python bootstrap.py $ ./bin/buildout and they will have a Plone 3 instance to develop from. I won't be helping anyone set up Plone in another way, simply because from previous sprints I know that we waste an awful lot of time on something so simple as getting people to symlinks eggs around (yipes). During Plone 3 development, dealing with two bundles (which meant each review bundle needed two bundles as well) that explicitly check out various eggs was a pain in the ass as well. Something that automates this is very useful. I started instancemanager for the same reason: to do away with hour-long bughunts just because someone had an old product lying around. From what I understand, Jean-Paul has an instancemanager configuration that builds a nice plone 3.0 instance from the normal, unmodified bundle with just a few lines of instancemanager configuration. Just keep the bundle sane and everything should be OK. Either buildout/ploneout or instancemanager can help. The goal is the same. Reinout -- Reinout van Rees r.van.rees @ zestsoftware.nl http://vanrees.org/weblog/ http://zestsoftware.nl/ Military engineers build missiles. Civil engineers build targets. ___ 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 )
