Re: [Zope3-dev] psycopgda egg
On 10.10.2007, at 16:27, Sidnei da Silva wrote: Has anyone eggified psycopgda? I can't find mention of an egg for it anywere. I would be pretty surprised that no-one did this so far. we're adding http://initd.org/pub/software/psycopg/ psycopg2-2.0.6.tar.gz to our [find-links] section in buildout.cfg and require psycopg2 in setup.py jodok -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Although practicality beats purity. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zeo on solaris
hi, it seems like we're going to deploy a pretty big installation on a combination of solaris / RHEL servers. the data storage of our application is based on ZODB (ZEO) and PostgreSQL (with STORM) plus NFS for extfile handling. so far it's planned to deploy ZEO, PostgreSQL and NFS on a fully redundant SUN Fire 440 with Solaris connected to a Hitachi/Sun StorEdge 9990 SAN. i know ZOPE has/had some issues on Solaris (http://www.zope.org/ Members/glpb/solaris) we're talking about ZEO/PostgreSQL only... we guys at lovely systems don't have a lot of experience with solaris, who of you guys is running ZEO on solaris? how does it perform? we'd like to contract someone with solaris expertise in near future, volunteers - contact me :) thanks for your feedback jodok -- Simple is better than complex. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
On 04.10.2007, at 15:57, Jim Fulton wrote: Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. +1 Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jodok% 40lovelysystems.com -- Simple is better than complex. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists
On 04.10.2007, at 16:02, Baiju M wrote: Jim Fulton wrote: Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. +1 What about retiring #zope3-dev IRC channel and only using #zope ? separate issue, but +1 Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Complex is better than complicated. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zc.testbrowser alpha 1 released
hey benji, do you see a chance to use zc.testbrowser on remote (headless) machines in combination with buildbot? jodok On 28.09.2007, at 16:06, Benji York wrote: zc.testbrowser 1.0a1 I am very pleased to announce the first alpha release of zc.testbrowser: http://pypi.python.org/pypi/zc.testbrowser zc.testbrowser is a refactoring of zope.testbrowser to remove the Zope-specific bits plus the addition of the zc.testbrowser.real module. Testbrowser Real zc.testbrowser.real lets you use the testbrowser API to drive a real web browser; at the moment Firefox (but we may add support for others in the future). This lets you do testing of JavaScript heavy web applications with testbrowser (and doctests, of course). I envision people often beginning tests using the regular testbrowser, realizing the test/documentation they want to write needs JS, and then switching their test to use real and not having to change the already written parts of the doctest. Screen Shots One other feature of zc.testbrowser.real is the ability to save the current web page to a PNG file. This should be very useful for creating user manuals with embedded screen shots. Thanks -- Many, many thanks to my partners in crime at the Foliage Sprint: Stephan Richter, Rocky Burt, and Justas Sadzevičius. Bikeshedding Request Even though I coined it, I don't really like the name real. I'd like suggestions that are short, pithy, and descriptive if anyone has any. Along the same lines, any suggestions for a new name for zc.testbrowser.browser (the classic testbrowser) would be appreciated as well. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Complex is better than complicated. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] faulty eggs (2)
**sigh** this morning i replaced the faulty *.zip eggs with new tar.gz releases: - zope.app.applicationcontrol - zope.app.appsetup - zope.app.session - zope.app.error - zope.error in case there are some other .zip eggs in the wild - please fix them asap. i don't blame anyone for releasing faulty eggs, but we should find a way to circumvent this in future. the working sets approach might be helpful... /me bans windows once more jodok -- If the implementation is hard to explain, it's a bad idea. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c.widget not on pypi?
On 18.09.2007, at 23:29, Wichert Akkerman wrote: I noticed that z3c.widget has a tagged release on svn but there is no cheeseshop entry for it. Is that on purpose? It would be practical to have it registered there. you bring up an interesting point... the current practice (at least here at lovely systems, and presumably a lot of other developers) is to add download.zope.org/distribution (or a mirror of it) to your find-links. recently some people started registering packages (and uploading eggs ) to cheeseshop. this makes totally sense for zc.buildout, lovely.buildouthttp,... but i'm not sure about zope packages. because of this mix you might end up in getting the wrong egg. or not finding a egg you downloaded a few days ago. in case pypi is down you're totally stuck. well, i understand that the stability of pypi is much better lately and the simple interface, the and ppix mirrors make the index lookup much faster as well. but for me there are still two remaining issues: - the eggs are hosted on cheesehop as well, it's not easy (commandline) to host the egg externally or to specify a mirror to use when pulling the eggs. that's not acceptable for production deployments. - by default setup.py sdist bdist_egg register upload hides the old releases, which is not acceptable as we nail all versions for deployments. if someone releases a new version, the older ones disappear and buildout (with nailed versions) stops and complains not finding the egg. before we don't have a solution for the two points above i have objections to register the packages on pypi and prefer to add download.zope.org/distribution to my find-links. if there is an easy solution for it, enlighten me :) jodok Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Although never is often better than *right* now. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: z3c.widget not on pypi?
On 19.09.2007, at 00:32, Philipp von Weitershausen wrote: Jodok Batlogg wrote: the current practice (at least here at lovely systems, and presumably a lot of other developers) is to add download.zope.org/ distribution (or a mirror of it) to your find-links. recently some people started registering packages (and uploading eggs ) to cheeseshop. this makes totally sense for zc.buildout, lovely.buildouthttp,... but i'm not sure about zope packages. We're certainly uploading a lot of Zope3's own eggs to PyPI *IF* - they have a decent description and long_description - they have decent metadata otherwise (Trove classifiers, changelog) - they're actual stable releases When packages fulfil these criteria, then I think it's very good to have them on PyPI: they're a great way to make them discoverable for other developers, Zope and non-Zope. For example, I can browse the 'Zope3' framework category and find a lot of Zope3-related software now. I wish more software were aptly classified with this Trove classifier so I could find more (all!) Zope3 software tehre. i just uploaded the z3c.widget 1.0.6 egg and am trying the use-cases below. because of this mix you might end up in getting the wrong egg. or not finding a egg you downloaded a few days ago. in case pypi is down you're totally stuck. You're stuck either way, even if you'd be using download.zope.org/ distribution. The key is to mirror the PyPI simple index. That's what ppix (or actually it's success zc.mirrorpypislashsimple) is all about. This is a non-issue I think. o.k. fine, you're actually right. i'm wondering why i couldn't fine zope.app.wsgi = 3.4.0b1dev_r75415 after 3.4.0 was released a few days ago. probably someone in [philikon, ctheune, J1m, baijum] removed the egg? we nailed the version to 3.4.0b1dev_r75415 (and i have still this egg in my cache), but it disappeared from the rest of the world. this should never happen for released eggs, they should be considered read-only imho. sorry for blaming pypi/setuptools for this :) well, i understand that the stability of pypi is much better lately and the simple interface, the and ppix mirrors make the index lookup much faster as well. but for me there are still two remaining issues: - the eggs are hosted on cheesehop as well, it's not easy (commandline) to host the egg externally or to specify a mirror to use when pulling the eggs. that's not acceptable for production deployments. I think it's really easy. Just use Jim's mirror software and point buildout to that different index. That's one line in buildout.cfg. Again, seems like a non-issue. i'm not talking about the index, i mean the actual download. http:// download.zope.org/ppix/z3c.widget/ still points to pypi.python.org is there a way to change this? mirror it? - by default setup.py sdist bdist_egg register upload hides the old releases, which is not acceptable as we nail all versions for deployments. if someone releases a new version, the older ones disappear and buildout (with nailed versions) stops and complains not finding the egg. It doesnt' disappear from the simple index. It just disappears from the human index, which I think is a good idea. It doesn't make sense to show people a billion releases. setuptools and zc.buildout (which both nowadays use the simple index) will obviously need to know about the odl releases. This is a non-issue :). agree before we don't have a solution for the two points above i have objections to register the packages on pypi and prefer to add download.zope.org/distribution to my find-links. if there is an easy solution for it, enlighten me :) Human discoverability is *very* important. If you have doubts about depending on PyPI, fine. I won't mind a backup location (though I hate download.zope.org/distribution. It has piled up so many crappy eggs by now with no way of deleting them...). But please don't take the human discoverability away from it all. I thikn that's what PyPI is great for. Provided you actually make it worthwhile and have meaningful package metadata in setup.py. Bis morgen :) bis morgen :) jodok -- http://worldcookery.com -- Professional Zope documentation and training -- Explicit is better than implicit. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Lovely Zope3 Taming
Even Girls can learn it! Your Trainer is wolf famous Zope Tamer Philipp von Weitershausen. September 19th - 21st (that's soon!) for more information: http://www.lovelysystems.com/batlogg/2007/09/14/ lovely-zope3-taming/ cheers Jodok -- Beautiful is better than ugly. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Lovely Zope3 Taming
On 14.09.2007, at 11:47, Ivan Horvath wrote: Dear Jodok, can you also propose some accommodation for this event? just contact [EMAIL PROTECTED] - she'll organize something for you in case you are interested. jodok ps.: please contact me / maria-anna ([EMAIL PROTECTED]) directly and don't cc the lists in future. On 9/14/07, Jodok Batlogg [EMAIL PROTECTED] wrote: Even Girls can learn it! Your Trainer is wolf famous Zope Tamer Philipp von Weitershausen. September 19th - 21st (that's soon!) for more information: http://www.lovelysystems.com/batlogg/ 2007/09/14/ lovely-zope3-taming/ cheers Jodok -- Beautiful is better than ugly. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 ___ Zope3-users mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope3-users -- Sparse is better than dense. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: skin support for xmlrpc
hi christian, On 24.08.2007, at 15:12, Stephan Richter wrote: On Friday 24 August 2007 02:37, Christian Zagrodnick wrote: The term skin is probably missleading but was taken to keep it simple. It's more an api-set. Then don't use it! Misusing a concept can lead to a lot of confusion. it's misleading for me as well :) Usecase: Different API on the same server We have a lot XML-RPC methods defined for ISite which get all their data in. This is quite unlike one would register XML-RPC mehtods normally, but the clients using the interface are not sophisticated enough. Now there are different systems talking with Zope. The systems have some things in common, some not. One systems calls a method, say list_foo anonymous, while another needs to authenticate for list_foo. The idea is now to register list_foo for different layers/skins/api-sets. This could also be achieved by creating dummy model-objects and/or traversers, but would be much less understandable. What essentially happens is that the views are registered for different request types. You can solve this issue easily using pluggable traversers. There is absolutely no need to use skins here. For example, a traverser plugin can simply mark the request with a directly provided interface and return the same object. This would work very much like a skin without mis- using the concept. for me xmlrpc is remote procedure call. a rpc has a signature and always the same result. and as stephan said - traversers should help here. Usecase: Authenticate Users depending on the skin As i said before there are different systems which need to authenticate. The systems have disjunctive sets of users with potentially the same login names. There needs to be a way to authenticate without guessing which set of users we're talking about. This could also be achieved by a custom traverser or namespace. Then use a custom traverser, please!? :-) +1 It probably would not be much of a problem to remove the skin things again and put it directly to the project or another third-party component. But it doesn't feel right. Please revert the skin support again. This is a pretty major change and I gave a -1 on the original discussion already. There was never a full proposal either. -1 from here as well. jodok Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- In the face of ambiguity, refuse the temptation to guess. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] skin support for xmlrpc
On 27.08.2007, at 22:11, Christian Theune wrote: Hi, Am Freitag, den 24.08.2007, 07:55 +0200 schrieb Jodok Batlogg: hi christian, it seems like your recent changes to support skins in xmlrpc views introduced some troubles. we spent several hours to debug not working xmlrpc views and finally found that nailing the zope.traversing egg to 3.4.x resolved the troubles. while looking at your changes we were wondering why you want to support skins in xmlrpc views? for me, a xmlrpc call is a remote procedure call and has to do nothing with skins. it's not yellow, pink or orange and has no templates associated. can you explain your use-case for this? Let me try to wrap some of the things up here. When we drafted this change, we followed the idea of the refactoring for skins as they are now (switching from a separate skin/layer implementation to the current marker interfaces on requests) which was very technically focused. So were we. I see that we're misusing the ++skin++ traversal namespace and should introduce another namespace instead. Our mistake. We introduced the change as we thought it to be straightforward and a logical extension. As stated above we overlooked the simple solution of another traverser. We did not anticipate it to be such a strong problem otherwise we'd created a separate proposal instead of just going forward. Zagy posted a reply to your question for a use case on that thread in the checkins list [1] but unfortunately that thread died off with this message and nobody returned to it. Let me propose a change: 1. We revert the change. 2. We create a new traverser with a different namespace that implements our intended behaviour. Two options after that: 3a. We supply this traverser by default, or 3b. We ship it in a separate package. I do have the feeling that differentiating the XML/RPC-API based on specifics of the request are of value (it certainly is for us) as are skins. perfectly fine. i prefer the separate package :) jodok If we can decide to ship a new traversal namespace for zope.publisher then we'd be happy to do that. Otherwise we'll just go on with a separate package. Hooray for the CA. Christian [1] ... http://mail.zope.org/pipermail/checkins/2007-August/ 012638.html ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Simple is better than complex. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot.zope.org
hi, it seems that http://buildbot.zope.org/ seems to be pretty borked. iirc benji is taking care of the build master and other people are maintaining the slaves. in case we don't have enough slave maintainers, lovely systems would be happy to provide a slave for linux 2.6 and make sure this slave is up and running. testing single eggs is pretty easy, i'm unsure how we should test the integration of the eggs. some eggs are compatible with 3.4.x, others introduced incompatible chances and need newer dependent eggs. how do you guys think about it? thanks jodok -- Simple is better than complex. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] skin support for xmlrpc
hi christian, it seems like your recent changes to support skins in xmlrpc views introduced some troubles. we spent several hours to debug not working xmlrpc views and finally found that nailing the zope.traversing egg to 3.4.x resolved the troubles. while looking at your changes we were wondering why you want to support skins in xmlrpc views? for me, a xmlrpc call is a remote procedure call and has to do nothing with skins. it's not yellow, pink or orange and has no templates associated. can you explain your use-case for this? thanks jodok -- Explicit is better than implicit. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Page Template Bug??
On 08.08.2007, at 00:39, Luis De la Parra wrote: Hello all, I just decided to give ExtJS a try, and while taking a look at their javascript templates, I think I found a bug in the template parsing of zope: trying to access a page that just serves the template below, fails with the message: error msg=== [...]zope.pagetemplate-3.4.0a1-py2.4.egg/zope/pagetemplate/ pagetemplate.py, line 109, in pt_render - Warning: Compilation failed - Warning: zope.tal.htmltalparser.NestingError: Open tags html, body, script do not match close tag /div, at line 12, column 35 PTRuntimeError: ['Compilation failed', 'zope.tal.htmltalparser.NestingError: Open tags html, body, script do not match close tag /div, at line 12, column 35'] = it seems like the parser sees the closing /div, but misses the opening one. I tried commenting out !-- -- the script contents, but got the same problem. (If I comment the script tag as a whole, then the page gets served, but that doesn't bring me anything =( ) you can't put a div /div inside your script tag... the expression tal:attributes=src static/ext-base.js makes no sense to me as well :) i recommend reading http://plone.org/documentation/tutorial/zpt cheers jodok test.pt === html head script src=../static/ext-base.js type=text/ javascript tal:attributes=src static/ext-base.js/script script src=../static/ext-all-debug.js type=text/ javascript tal:attributes=src static/ext-all-debug.js/script /head body ExtJS Test div id=testidthis is a test/div script language=JavaScript var tpl = div js-template /div var view = new Ext.JsonView(testid, tpl); /script /body /html regards, luis ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Namespaces are one honking great idea -- let's do more of those! -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Fwd: Preferring final releases
On 05.07.2007, at 16:35, Philipp von Weitershausen wrote: Jim Fulton wrote: There's a question below that I want opinions on, so I'm forwarding this note here that I sent to the distutils-sig. I'd prefer answers there, but I'll take them here. Specifically: Should I make it the default policy for buildout to prefer final releases? I think this is the right thing to do in the long run, however, it will cause buildouts that implicitly use non-final eggs to be downgraded. This will cause some pain until people make adjustments. +1 to making 'prefer-final = true' the default +1 too -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Simple is better than complex. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
On 02.07.2007, at 20:54, Jim Fulton wrote: See me response to Gary's note. Here's what I propose: 1. We adopt the policy that a distribution's version number must be of less or equal maturity than all of it's dependencies, where maturity is based on it's position in the release cycle. dev is less mature than alpha is less mature than beta is less mature than release candidate is less mature than final. So, for example, dev release of zope.app.keyreference can depend on a dev release of ZODB3, but an alpha release of zope.app.keyreference cannot. Initially, this will be a convention. Eventually, I'll add a feature to buildout to warn when this policy is violated. +1 2. We approach the distutils sig with a feature request for an option to prefer final versions, so that, if we specify the new option, we always get the newest final version that satisfies a requirement, if there is one. I suggest that this be --prefer- final. Anyone want to volunteer to bring this up there? :) I don't think we'll see this feature any time soon. +1 3. I add a prefer-final option to buildout to prefer final versions. I think I can do this in the next week. +1 Thoughts? Jim On Jun 27, 2007, at 10:01 AM, Christian Theune wrote: Hi, the recent introduction of zope.app.keyreference-3.5dev with it's dependency on ZODB 3.9 brought some issues for me as I get conflicts in various buildouts (e.g. z3c.zalchemy). In my example, z3c.zalchemy doesn't care about which version of zope.app.keyreference it gets, as even the newer one won't affect us. I'd like to re-visit the discussion about stable package versions and how to approach the distutils list to get what we want. Currently I resolve this issue by putting a specific version in my project's buildout and leave the package (e.g. z3c.zalchemy) alone. I'm not sure whether this is the strategy we should use. Should z3c.zalchemy say: I'm good with zope.app.keyreference==3.4 (with our proposed syntax, or 3.5dev with the current syntax)? I'd like to see some consensus on how we handle those ... Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Special cases aren't special enough to break the rules. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: AW: deprecate ++etc++site/default?
On 21.06.2007, at 22:57, Bernd Dorn wrote: On 20.06.2007, at 08:01, Christian Zagrodnick wrote: Note that adding a subitem called 'default' won't be allowed: site_manager['default'] = object() Traceback (most recent call last): ... Your -1 goes was for this part, was it not? yes, i want to be able to add a subitem called default same here ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- Sparse is better than dense. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On 30.05.2007, at 21:30, Jim Fulton wrote:
On May 30, 2007, at 3:20 PM, Christian Theune wrote:
Hi,
Am Mittwoch, den 30.05.2007, 15:12 -0400 schrieb Benji York:
Jim Fulton wrote:
It's actually worse than that. 2.0 would admit 2.0a1. :) You'd
probably need something like 1.99.
I can deal with spelling dependencies on major version X as = X.
999.
Even if developers remembered, it would be icky to have to spell
out
something like =3.4 =3.99 on everwhere.
Not as icky (IMHO) as having distribution names with embedded major
version numbers. I'm interested in other people's opinions here.
I don't like version numbers encoded in package names. I consider
this
to be a work-around for packaging systems that aren't rich enough.
(Gentoo for example gets this right.)
Could you elaborate on this?
well :) i'm co-maintainer of the net-zope herd in gentoo:
read my attempt to improve the plone versioning: http://
article.gmane.org/gmane.comp.web.zope.plone.devel/3227/match=version
+gentoo+batlogg
in summary:
Naming release tarballs (adapted from the gentoo conventions ;-))
file names consist of three logical sections:
The first section is the package name, which should only contain
lowercase
letters, the digits 0-9, and any number of single hyphen ('-') or
underscore ('_') characters. Some examples are cmfplone,
cmfquickinstaller,
formulator,...
The second section is the version of the package, which should
normally be
same as the version of the contained product. The version is normally
made
up of two or three numbers separated by periods, such as 1.2 or
4.5.2, and
may have a single letter immediately following the last digit; e.g.,
1.4b
or 2.6h. The package version is joined to the package name with a
hyphen;
for example: foo-1.0, bar-2.4.6, etc.
Important: If you're thinking of using a trailing letter in your version
string, note that the trailing letter should not be used to signify
alpha
or beta status for the package, since alphas and betas are
prereleases and
letter revisions are newer versions. It's very important that version
numbers faithfully represent the version of the package so that
depenency
checking is possible.
The third (optional) section contains a special suffix; either _alpha,
_beta, _pre (pre-release), _rc (release candidate), or _p (patch).
Any of
these suffixes may be immediately followed my a number; e.g.,
linux-2.4.0_pre10; Assuming identical version parts, an _alpha
package is
older than _beta, _beta older than _pre, _pre older than _rc, and _rc
older
than _p. This section is meant to reflect upstream versions only.
Note: An _rc package is older than a package without an underscore
prefix
(i.e. linux-2.4.0), and linux-2.4.0 is older than a package with a
single
letter prefix, i.e. linux-2.4.0b. As you would expect, the linux-2.4.0b
package is considered older than linux-2.4.0c.
... and I suppose that we actually have a fourth section of the file
name --
the .tar.gz extension itself.
Maybe there is some kind of dependency syntax that reads well that
means I want this major version. Can you think of a syntax
that is
actually nicer than foo2?
I can think of a syntax, but don't know if setuptools supports it.
Perhaps I should look that up. But I wont.
I read the documentation on the version numbers multiple times and
can't
remember anything that supports our use case.
Maybe we should as pje whether there is something like what we
imagine?
I think I know what the answer will be. After all, there is a
syntax for getting what we want. The problem with it, IMO, and I
think in other people's opinion is that it is too cumbersome.
IMO, having every dependency look like:
project_name =X.y.z X.999
Is too cumbersome. Maybe we should get over that. Maybe many other
people don't think it's too cumbersome. Alternatively, maybe
someone can think of a prettier/more-concise syntax and sell it to
PJE.
I'll note that this is especially cumbersome if, as I believe, for
90% of packages, there isn't any good reason to make backward
compatible changes, at least after initial development. So all
packages would end up getting a dependency-specification tax even
though only a few packages will need backward compatibility changes.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists%
40lovelysystems.com
--
In the face of ambiguity, refuse the temptation to guess.
-- The Zen of Python, by Tim Peters
Jodok Batlogg, Lovely Systems
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
phone: +43 5572 908060, fax: +43 5572
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On 30.05.2007, at 22:20, Jim Fulton wrote:
On May 30, 2007, at 3:36 PM, Jodok Batlogg wrote:
On 30.05.2007, at 21:30, Jim Fulton wrote:
On May 30, 2007, at 3:20 PM, Christian Theune wrote:
Hi,
Am Mittwoch, den 30.05.2007, 15:12 -0400 schrieb Benji York:
Jim Fulton wrote:
It's actually worse than that. 2.0 would admit 2.0a1. :) You'd
probably need something like 1.99.
I can deal with spelling dependencies on major version X as =
X.999.
Even if developers remembered, it would be icky to have to
spell out
something like =3.4 =3.99 on everwhere.
Not as icky (IMHO) as having distribution names with embedded
major
version numbers. I'm interested in other people's opinions here.
I don't like version numbers encoded in package names. I
consider this
to be a work-around for packaging systems that aren't rich enough.
(Gentoo for example gets this right.)
Could you elaborate on this?
well :) i'm co-maintainer of the net-zope herd in gentoo:
read my attempt to improve the plone versioning: http://
article.gmane.org/gmane.comp.web.zope.plone.devel/3227/
match=version+gentoo+batlogg
tmi :)
in summary:
Naming release tarballs (adapted from the gentoo conventions ;-))
file names consist of three logical sections:
The first section is the package name, which should only contain
lowercase
letters, the digits 0-9, and any number of single hyphen ('-') or
underscore ('_') characters. Some examples are cmfplone,
cmfquickinstaller,
formulator,...
The second section is the version of the package, which should
normally be
same as the version of the contained product. The version is
normally made
up of two or three numbers separated by periods, such as 1.2 or
4.5.2, and
may have a single letter immediately following the last digit;
e.g., 1.4b
or 2.6h. The package version is joined to the package name with a
hyphen;
for example: foo-1.0, bar-2.4.6, etc.
Important: If you're thinking of using a trailing letter in your
version
string, note that the trailing letter should not be used to
signify alpha
or beta status for the package, since alphas and betas are
prereleases and
letter revisions are newer versions. It's very important that version
numbers faithfully represent the version of the package so that
depenency
checking is possible.
The third (optional) section contains a special suffix; either
_alpha,
_beta, _pre (pre-release), _rc (release candidate), or _p (patch).
Any of
these suffixes may be immediately followed my a number; e.g.,
linux-2.4.0_pre10; Assuming identical version parts, an _alpha
package is
older than _beta, _beta older than _pre, _pre older than _rc, and
_rc older
than _p. This section is meant to reflect upstream versions only.
Note: An _rc package is older than a package without an underscore
prefix
(i.e. linux-2.4.0), and linux-2.4.0 is older than a package with a
single
letter prefix, i.e. linux-2.4.0b. As you would expect, the
linux-2.4.0b
package is considered older than linux-2.4.0c.
... and I suppose that we actually have a fourth section of the
file name --
the .tar.gz extension itself.
I don't see how this helps one say that they want to depend on a
minimum version of a major version. That is, how does it prevent
dependencies like:
foo =1.0 1.999
?
I'm wondering how Gentoo got *that* right.
you are able to specify dependencies (http://devmanual.gentoo.org/
general-concepts/dependencies/index.html) like:
=app-misc/foo-1.23 Version 1.23 or later is required.
app-misc/foo-1.23 A version strictly later than 1.23 is required.
~app-misc/foo-1.23 Version 1.23 (or any 1.23-r*) is required.
=app-misc/foo-1.23 Exactly version 1.23 is required. If at all
possible, use the ~ form to simplify revision bumps.
=app-misc/foo-1.23 Version 1.23 or older is required.
app-misc/foo-1.23 A version strictly before 1.23 is required.
jodok
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists%
40lovelysystems.com
--
Namespaces are one honking great idea -- let's do more of those!
-- The Zen of Python, by Tim Peters
Jodok Batlogg, Lovely Systems
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
phone: +43 5572 908060, fax: +43 5572 908060-77
smime.p7s
Description: S/MIME cryptographic signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
On 30.05.2007, at 23:25, Christian Theune wrote: Am Mittwoch, den 30.05.2007, 17:13 -0400 schrieb Jim Fulton: How would you say that you want version 1.23 or higher but less than any version 2? I re-read their spec and they say: =sys-apps/foo-1.2* will select the newest member of the 1.2 series, but will ignore 1.3 and later/earlier series. That is, foo-1.2.3 and foo-1.2.0 are both valid, while foo-1.3.3, foo-1.3.0, and foo-1.1.0 are not. exactly :) Note that the equals sign is mandatory, and that there is no dot before the asterisk. -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development -- Explicit is better than implicit. -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
