[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Mon Feb 5 12:00:00 2007 UTC to Tue Feb 6 12:00:00 2007 UTC. There were 9 messages: 9 from CMF Unit Tests. Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:40:38 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004001.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:42:08 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004002.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:43:38 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004003.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:45:08 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004004.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:46:38 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004005.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:48:08 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004006.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:49:38 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004007.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:51:08 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004008.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Mon Feb 5 21:52:38 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-February/004009.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Feb 5, 5:40 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 5 Feb 2007, at 19:43, Rocky Burt wrote: On Feb 2, 4:41 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: OK, sounds good, I misunderstood your email. I suppose the last bit left to do now is the custom site manager. Rocky? :) Yep, looks like I'll be starting on five.localsitemanager pretty soon. Although I didn't see if we decided anywhere how that would get included with CMF (with plone it's pretty simple as we already distribute python/lib stuff). Not knowing any better I was assuming there'd be a Zope 2-style product, which we could pull in as a SVN external? Hm... well, as long as I avoid absolute imports in five.localsitemanager there's no reason it couldn't be included into a CMF product (perhas CMFCore ?) via svn:externals. That's not something I'm particularly fond of but I'm not against it. But as time moves on this is going to become more and more of an issue for CMF (code that isn't expected to live in Products/). - Rocky ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
On Feb 6, 5:45 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: Right now all you need to do to install CMF is to link all the contained folders into the instance Products folder. I'm somewhat averse to complicate that process. I understand the sentiment and we dealt with the same thing for Plone. I know at one point someone (I think Philipp) suggested that we could actually place the products we have into lib/python/ instead of the Products/ directory for Plone by using an empty namespace package for Products (so CMFCore would become lib/python/Products/ CMFCore). I haven't tested this myself but if it's ease of deployment you're looking for, perhaps extracting everything there would do the trick. Ultimately the closer we get to structuring our code deployment like regular python code the easier it will be to take advantage of things like distutils, eggs, the cheeseshop, etc. I look forward to doing: easy_install ZopeCMF - Rocky ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: List available on groups.google.com
On Feb 5, 5:43 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: Hm... I thought gmane was plenty as far as searchable web integration goes. I don't use web interfaces to mailing lists, so I'm not sure where the advantage is. For me it's just the simple fact that I prefer using the google groups UI over the gmane UI. There's no reason we can't have both available. Really I just created this google setup as I was moving away from my old nntp:// based reader and figured I'd let everyone know it exists. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
Am 06.02.2007 um 22:14 schrieb Rocky: Ultimately the closer we get to structuring our code deployment like regular python code the easier it will be to take advantage of things like distutils, eggs, the cheeseshop, etc. I look forward to doing: easy_install ZopeCMF I hate eggs and easy_install and for me they are not part of regular python code but reminiscent of script kiddy magic dust which I *really* don't want in my apps. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Feb 2007, at 00:36, Martin Aspeli wrote: Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. Well, for simple work with the CMF like setting up a quick instance for hacking and development *I do not want to use any tools*. I want to retain the same ease I currently have where all I need to do is either copy or link a few directories into the instance Products folder. It's intuitive and very fast for a Zope 2 developer. If you can offer the same ease and speed with a different approach, fine. But I don't see it with those wondrous tools. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFyRMtRAx5nvEhZLIRAvlnAKCT0RM5RZ4gs3wfoLxrDZ/wT81PvwCeNMdk GZVIDO16jeYQV6XSKRTCJZk= =//MN -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
Am 07.02.2007 um 00:36 schrieb Martin Aspeli: Why? Is it the ability to specify sensible version restrictions? Have multiple versions of the same package as different dependencies for different dependents? Automatic downloading of dependencies where possible/desired? Standardised package metadata? Standardised location to find and search for add-on libraries? You mean the existing approach didn't support this? Ever heard of sys.path? Sorry, I don't want to waste bandwidth on the CMF list on a flame war. Eggs are there and I will have to learn to live with them but I don't have to like them. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. Meanwhile, the rest of the Python world came up with something better and more widely accepted. Until Zope 2.10 and Plone 3, the whole Plone and CMF stack depended on no library that was re-usable outside of Zope (apart from PIL, and unless you count parts of Zope 3 shipped with Zope 2.8+). Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. This is guff. Why should Zope add-ons *necessarily* be available as third-party libraries? But if this is required it's no big deal to put the Zope specific stuff in a Products folder and the library in ../lib/python. Works fine for mxODBC Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Feb 2007, at 00:36, Martin Aspeli wrote: Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. Well, for simple work with the CMF like setting up a quick instance for hacking and development *I do not want to use any tools*. I want to retain the same ease I currently have where all I need to do is either copy or link a few directories into the instance Products folder. It's intuitive and very fast for a Zope 2 developer. If you can offer the same ease and speed with a different approach, fine. But I don't see it with those wondrous tools. For Plone 3 development, we have two solutions (depending on which one you prefer). I'll explain them briefly to give you a flavour of how they may work. The first is called ploneout, and is a zc.buildout. We had to create a couple of recipes to play nice with Zope 2, but these would work fine with CMF. Basically, all ploneout is, is a particular buildout.cfg that references Plone's eggs and products via svn:externals, in development mode (as opposed to as dependencies). This also downloads builds Zope 2.10 and all other dependencies, in a single command (though if you want to point to an existing Zope install to save space, you can). $ svn co https://svn.plone.org/svn/plone/ploneout/trunk plone3 $ cd plone3 $ python boostrap.py # only needed once $ bin/buildout # needed each time you change buildout.cfg $ bin/instance fg # start zope What's nice is that we can point new developers at this and they have a fully replicable environment for proper development on Plone 3 itself. The plone eggs are in src/ and products in products/, via svn:externals, so you can work on them and then commit changes. If you were using this for your own project and you wanted to Plone, CMF and all the eggs only as a dependency, maybe with your own eggs and products in development mode, you can create a buildout.cfg by answering a couple of questions (or accepting the defaults) from paster. $ easy_install ZopeSkel # gets Zope/Plone templates for paster $ paster create -t plone3_buildout myproject $ cd myproject $ python bootstrap.py $ bin/buildout The buildout.cfg file contains a list of the eggs you want, and you tend to put development eggs for your project in src/ and reference them in buildout.cfg. Daniel Nouri has a slightly different approach, using workingenv.py. Whereas buildout.cfg is a single-file configuration for the eggs, downloads and other build steps you want in your environment, his ploneenv approach creates a more traditional Zope instance. It's more for projects using Plone as dependency again, because it basically installs the Plone egg, which in turn keeps track of all the various eggs we have as dependencies and all the products. There could be a CMF meta-egg that'd work similarly. $ easy_install ploneenv $ ploneenv -m /path/to/zope/utilities/mkzopeinstance.py myproject $ bin/zopectl fg # as usual The workingenv approach lets you install eggs into it, not interfering with global site-packages, using the local bin/easy_install. If you prefer, you can source bin/activate and it'll set your PATH and PYTHONPATH as necessary so that your shell is always in the local environment. decativate (or quitting your shell) turns that off again. Martin ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Charlie Clark wrote: Am 07.02.2007 um 00:36 schrieb Martin Aspeli: Why? Is it the ability to specify sensible version restrictions? Have multiple versions of the same package as different dependencies for different dependents? Automatic downloading of dependencies where possible/desired? Standardised package metadata? Standardised location to find and search for add-on libraries? You mean the existing approach didn't support this? Ever heard of sys.path? Sure, I mean, that's all they do, manage sys.path for you. But it's way easier to be more declarative about your dependencies and their versions, and having automatic downloads of dependencies (even indirect ones) can save a lot of time and make it easier to try things out. Sorry, I don't want to waste bandwidth on the CMF list on a flame war. Eggs are there and I will have to learn to live with them but I don't have to like them. I'm not quite sure it's wasted bandwidth in the sense that I believe moving to distribution using eggs could benefit CMF and its dependents greatly. This pressure is coming from both sides: Zope (3) and Plone. I'm pretty sure the Silva guys are fairly enthusiastic about eggs, too. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. Meanwhile, the rest of the Python world came up with something better and more widely accepted. Until Zope 2.10 and Plone 3, the whole Plone and CMF stack depended on no library that was re-usable outside of Zope (apart from PIL, and unless you count parts of Zope 3 shipped with Zope 2.8+). Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. This is guff. Why should Zope add-ons *necessarily* be available as third-party libraries? But if this is required it's no big deal to put the Zope specific stuff in a Products folder and the library in ../lib/python. Works fine for mxODBC Managing lib/python manually is quite painful. For example, we have a lot of things we want to keep in the plone.* namespace. These are developed by different people. When people had to symlink things in (before we got eggs) or we were building bundles, merging multiple packagings of libraries into lib/python/plone/ and lib/python/plone/app became difficult, time-consuming and really, really hard to explain to newbies. Mostly, I'm basing this on empirical evidence, though. In the latter part of the Plone 3 development cycle, we started pushing eggs pretty hard. We got familiar with tools like paster, setuptools and easy_install which help make this fairly painless. Before Plone 3, we made no use of external, non-Zope specific libraries (apart from PIL); to be honest, we hardly even looked for them, because of the distribution headache (Plone at that point was a tarball for Products/). Now, we've got half a dozen or so packages that other people (primarily Zope 3 people for now, but as Zope 3 becomes eggified as well it gets easier to re-use things outside Zope entirely) can use (grok is playing with our AJAX infrastructure, for example). We also know that we can find, try and ultimately declare dependencies for packages quite easily. I don't think eggs/setuptools are perfect. But I don't think they're useless either, and on the whole, so far, they've brought more benefits than problems. By playing with eggs, we're playing better with the rest of the Python community (and things like entry points are very cool). We start being able to re-use some of their tools (workingenv, buildout, paster) and participate more meaningfully by sharing code. In any case, I don't mean this to be acrimonious in any way. I'm justing saying that depending on a non-Products package (be it egg-distributed or not) shouldn't be a problem (because there will only be more and more of these). Martin ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Charlie Clark wrote: Am 06.02.2007 um 22:14 schrieb Rocky: Ultimately the closer we get to structuring our code deployment like regular python code the easier it will be to take advantage of things like distutils, eggs, the cheeseshop, etc. I look forward to doing: easy_install ZopeCMF I hate eggs and easy_install and for me they are not part of regular python code but reminiscent of script kiddy magic dust which I *really* don't want in my apps. I can see why people would be appalled by easy_install, at least in its default incarnation (inside a workingenv or a zc.buildout it's quite nice). There's little to be afraid for concerning eggs, though. They're just directories with Python packages in them (they often come in a ZIP form and may also be installed that way, which doesn't chagne the fact that they're just directories with Python packages in them). I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. I have no idea what local Products should be, but the Products package contains more magic than anybody should have to handle. The whole reason we have zopectl debug and zopectl test instead of a simple debugzope and test script (like we do have in Zope 3) is that Zope wants an extra special treatment for its Products thing. Doese zopectl work on Windows? No, it doesn't, because it builds on zdaemon. There, Products sucks. If Products were usinig standard Python idioms like namespace packages, etc., we wouldn't have that problem. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Jens Vagelpohl wrote: On 7 Feb 2007, at 00:36, Martin Aspeli wrote: Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. Well, for simple work with the CMF like setting up a quick instance for hacking and development *I do not want to use any tools*. Who says you have to. It seems to me that the only people here complaining are the ones who aren't quite familiar with eggs yet. Also, I seem to detect a general tone of skepticism against the new tools that the greater Python community is building. I can only encourage people to take a look at thigns like workingenv and zc.buildout and at what the Zope and Plone communities have done with these tools. Perhaps they don't allow you to use simple symlinks for deployment, but perhaps they offer something similiar, something even easier and a few additional extra features perhaps? It's worth at least checking these things out. I want to retain the same ease I currently have where all I need to do is either copy or link a few directories into the instance Products folder. It's intuitive and very fast for a Zope 2 developer. If you can offer the same ease and speed with a different approach, fine. But I don't see it with those wondrous tools. Eggs contain Python packages. How you deploy the Python packages is your choice. If you like copying or symlinking, fine. And, heck, you can still symlink your products to Products. Nobody's getting rid of Products. But please-oh-please let us start developing new things in regular packages so that we can a) make use of the tools provided to us by the greater Python community b) ease other Python programmers into Zope (no more weird Products, no more Zope stinks, no more Zope is its own universe). Some of us *like* reaching out. c) make things easier for *ourselves* (being able to test a simple Python package outside the context of a full-blown Zope instance is a tremendous win). -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Martin Aspeli wrote: I don't think eggs/setuptools are perfect. But I don't think they're useless either, and on the whole, so far, they've brought more benefits than problems. By playing with eggs, we're playing better with the rest of the Python community (and things like entry points are very cool). We start being able to re-use some of their tools (workingenv, buildout, paster) and participate more meaningfully by sharing code. In any case, I don't mean this to be acrimonious in any way. I'm justing saying that depending on a non-Products package (be it egg-distributed or not) shouldn't be a problem (because there will only be more and more of these). Good points. To summarize: * eggs aren't the holy grail, but they bring many benefits. * at this point, we shouldn't create artificials hurdles that prevent us from putting new things into packages and hence taking advantages of eggs. Nobody's tearing down old walls, but at least let's not stop building new ones. That's all I can and will say in this matter. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Tools as local utilities
Rocky wrote: On Feb 5, 5:40 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: On 5 Feb 2007, at 19:43, Rocky Burt wrote: On Feb 2, 4:41 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote: OK, sounds good, I misunderstood your email. I suppose the last bit left to do now is the custom site manager. Rocky? :) Yep, looks like I'll be starting on five.localsitemanager pretty soon. Although I didn't see if we decided anywhere how that would get included with CMF (with plone it's pretty simple as we already distribute python/lib stuff). Not knowing any better I was assuming there'd be a Zope 2-style product, which we could pull in as a SVN external? Hm... well, as long as I avoid absolute imports in five.localsitemanager there's no reason it couldn't be included into a CMF product (perhas CMFCore ?) via svn:externals. Please don't. Relative imports are evil. It's seriously a big wart in Python 2 and will thankfully be fixed in Python 3. Until then I can only recommend absolute imports everywhere. Yes, they're more to type, but at least I've been bitten too often. That's not something I'm particularly fond of but I'm not against it. But as time moves on this is going to become more and more of an issue for CMF (code that isn't expected to live in Products/). Right. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Tools as local utilities
On 2/7/07, Charlie Clark [EMAIL PROTECTED] wrote: Am 07.02.2007 um 00:36 schrieb Martin Aspeli: Why? Is it the ability to specify sensible version restrictions? Have multiple versions of the same package as different dependencies for different dependents? Automatic downloading of dependencies where possible/desired? Standardised package metadata? Standardised location to find and search for add-on libraries? You mean the existing approach didn't support this? Yup, we sure mean that. Ever heard of sys.path? Yeah, which is what eggs use an manage for you. This is guff. Why should Zope add-ons *necessarily* be available as third-party libraries? They shouldn't. The point is that we want third-party libraries to be available as Zope add-ons in much the same way as Zope Products are. But if this is required it's no big deal to put the Zope specific stuff in a Products folder and the library in ../lib/python. Sure, but one of the things, the easy of use you talk about, is that if everything is products you can make an svn-bundle, and just check it out into the products directory. You can't do that if you need it to be in several places. I currently solve this with my own libraries by making Zope products for the libraries as well, that put the libraries into sys.path if they don't already exist there. But that's only possible with libraries that I have control over. Bildout, ploneout and workingenv are there to try to solve these problems. If you don't like *them* I fully understand. They annoy me since they install like, every again, which takes time, and their complicated, and developer packages that ue them often require me to create a new Zope-instance even if I don't want to. But eggs? Eggs are great. Instead of separately downloading, compiling and installing five packages, all you do is easy_install blah and it does it for you. I really don't see how anybody can gripe about that. And if you don't want to use it, then don't. Then download, compile and install each paclage separately of you have to. Nobody is FORCING you to use eggs. -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
