Re: [Zope3-dev] Please don't use svn.zope.org urls in distutils homepage urls
Well, probably I was to fast predicting the causes of my problem. They only thing I know is that a couple of months ago I could browse the repository without any problem and suddenly I start getting a default Apache page and a lot of permission denied errors while trying to do the same. I'm sure I was browsing the same URL (http://svn.zope.org) since I had it on my bookmarks. Oddly enough, after this message thread I can browse the repository again from the device and I swear I didn't change any proxy configuration or anything at all. Best regards Lorenzo El vie, 24-08-2007 a las 10:00 -0400, Jim Fulton escribió: On Aug 24, 2007, at 5:07 AM, Lorenzo Gil Sanchez wrote: Aha! After reading this message now I finally understand the reason I can't browse svn.zope.org with my Nokia N800[1] anymore. I don't see what one has to do with the other. This used to be quite useful since I could read lots of *.txt documents from zope3 and related projects just before sleeping. I wish I could do it again. Nothing we've done should get in the way of your Nokia N800. I've setup an Apache server just to see what user-agent my device is giving and this is what came out from the log: 192.168.1.15 - - [24/Aug/2007:11:00:32 +0200] GET / HTTP/1.1 403 3926 - Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux armv6l; U) Opera 8.5 [es_ES] Tablet browser 0.0.14 RX-34_2007SE_4.2007.26-8 So please, adjust the Apache configuation so N800 users can browse the repository again. We are only excluding setuptools. Not any other clients. Jim -- Jim Fultonmailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
Andreas Jung wrote at 2007-8-24 21:01 +0200: ... ACK on everything of that. But reading code comes before understanding code. And the visual impression of code has a strong impact on how we read code and on how we understand code. True, but do you really read code to satisfy an esthetical need? When I read code, I always need an understanding of this code -- usually because the code does not what I suppose it should do. I never read code just for pleasure. Reading effort is usually much smaller than the understanding effort. While many people in the Python community seem to prefer loose code, I can better read and understand dense code. I can also read and understand loose code and my total effort is not dominated by the reading part. Thus, I could e.g. analyse a postgres (locking) problem by understanding its source although the code was horribly loose because the other (much more essential) aspects have been excellent: like conceptial documentation, well chosen names, well documented source... While I do not tell others whether they should write loose or dense code, I refuse to follow their preferences in *my* code. You can specify rules for your repositories -- and I will obey them. If the rules go however significantly against my preferences, then this implies fewer contributions from my side. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
Philipp von Weitershausen wrote at 2007-8-24 20:24 +0200: ... I wonder how you can like this language with significant whitespaces and lots of underscore rules then :). In fact, I dislike Python's grouping by indentation (especially how it is implemented in the interactive interpreter) and a few other syntactical aspects (e.g. the need to explicitly specify the object parameter in a method definition). But other aspects are very nice and outweigh the syntactical nastiness. I do not see lots of underscore rules, maybe because I disregard PEP 8... For me, the Java style (getMainType) is easier readable than the one prefered in the Python runtime library (get_main_type). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
Fred Drake wrote: On 8/24/07, Stephan Richter [EMAIL PROTECTED] wrote: But if you prefer consistency, then we really should be staying with the Zope 3 style guide, This, of course, all depends on the answer to the question: Consistency with what? Zope 3 history? The larger Python community? (Don't think the world agrees on PEP 8...) Because my desire is to make individual Zope packages more widely adopted by the larger Python community and bring more people to Zope 3, I prefer PEP 8. As has been said of Python, more Python code will be written in the future than has been in the past, I hope the same is true of Zope. Hopefully, there are also more Zope users to come than we have ever had. Consistency is good, but we have to be consistent with the largest body of code/group of people as possible. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
--On 25. August 2007 08:51:44 -0400 Benji York [EMAIL PROTECTED] wrote: Fred Drake wrote: On 8/24/07, Stephan Richter [EMAIL PROTECTED] wrote: But if you prefer consistency, then we really should be staying with the Zope 3 style guide, This, of course, all depends on the answer to the question: Consistency with what? Zope 3 history? The larger Python community? (Don't think the world agrees on PEP 8...) Because my desire is to make individual Zope packages more widely adopted by the larger Python community and bring more people to Zope 3, I prefer PEP 8. As has been said of Python, more Python code will be written in the future than has been in the past, I hope the same is true of Zope. Hopefully, there are also more Zope users to come than we have ever had. Consistency is good, but we have to be consistent with the largest body of code/group of people as possible. Can someone please point out the major differences concerning Python code between PEP 8 and the Zope 3 style guide? -aj pgpl3EWCRn8Tj.pgp Description: PGP 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] setting up application dependencies
Martijn Faassen wrote: Benji York wrote: Darryl Cousins wrote: On Fri, 2007-08-17 at 19:24 +0200, Martijn Faassen wrote: I think my next step is to fix some dependencies for Grok to hard version numbers... I think that this is a good thing. I recently gave myself quite a bit grief with a careless bin/buildout which broke my application. To avoid that I need to be more specific in setup.py. (I haven't attempted it yet though). Specifying versions should be done by the application (buildout for example), not setup.py. If versions are put in setup.py they limit what others can do with the version requirements (e.g., relaxing them). The problem with this approach is that everybody setting up an application will need to know a lot about version numbers. I like reuse. I don't want to expose, say, all users of Grok, to a lot of version numbers they need to set. I thin that's actually a third case. So far we have projects, applications, and now frameworks (for lack of a better word). Grok strikes me as a framework because you want to specify a known-good set of versions, but not in an all-in-one application distribution. So, in case of Grok what we don't want is that everybody needs to hardcode all kinds of version numbers into their own buildout.cfg. *the same* version numbers, typically. I'm not sure what the right approach is there, a simple versions.cfg that contains the suggested versions might be sufficient. We'd want this list of version numbers to be maintained by the Grok developers instead. We could of course make our 'grokproject' tool generate the hardcoded dependencies for users, but that seems rather odd too. This means that if someone wants to update their grok-based application to a newer version of Grok (which requires a newer version of say, zope.security), they will still need to go in and edit their buildout.cfg. That sounds difficult to communicate and difficult to maintain. As above, perhaps grok_versions.cfg could be one of (or the only) thing your users download. That's an interesting thought, the Grok project can produce lots of code and distributions and when it's time for a release, you release the grok-1.2-versions.cfg that people can update their local grok-versions.cfg with. I wonder if that model would work for future releases of Zope 3. In case of Grok, I think we do have such a central place: grok's setup.py. If we hardcode version numbers there, there's no more need for people to start putting it in their buildout.cfg. It also means that if people require a newer version of a library that Grok also depends on, they will have to talk to the Grok developers and ask for an update. I think that may have good side effects: the grok developers can then first test with this updated library and after a new version of Grok is released, everybody will have the benefit of the newest version of the library. That level of rigidity doesn't sound like much fun to me. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
Andreas Jung wrote: Can someone please point out the major differences concerning Python code between PEP 8 and the Zope 3 style guide? The primary differences are in method, attribute, function, and variable names. PEP 8 specifies lower_case_with_underscores. Zope 3, more often than not (as noted by others, inconsistencies exists), follows these conventions: http://wiki.zope.org/zope3/ZopePythonNamingConventions specifies CamelCase for Public global variables (not exactly sure what all that encompasses) and lower_case_with_underscores for local variables. The same page prescribes mixedCase for module-level (non-factory) functions. http://wiki.zope.org/zope3/ClassesAttributesMethods specifies mixedCase for attributes and methods. BTW: http://wiki.zope.org/zope3/CodingStyle (like most of the Wiki) is a mess. I may cut out some outdated chunks (including 5 year old comments) if no one objects. Are there any guidelines for the wiki? I looked but couldn't find any. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Guide for maintaining software in the Zope repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: On 24 Aug 2007, at 18:55 , Fred Drake wrote: I don't really care whether the style is the classic Zope 3 style or PEP 8, as long as it never changes. With this you seem to suggest we should continue using the classic Zope 3 style. - -1 to PEP8 (which is *not* universal in the Python community, as Fred pointed out; in particular, it makes choices which seem more appropriate to single-module code than namespaced-packages) +1 to Zope3 (and note that I have alreay moved there myself). That style is already documented; we should not need to expend any significant effort maintaining it. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0FA4+gerLs4ltQ4RArnIAJ9UuaJISJCj81MTlBqlButvhJrnfACfeC+M 3KLIrSwi6hIOE0a7e6Ky2lM= =fC8y -END PGP 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: RFC: Guide for maintaining software in the Zope repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/25/07, Tres Seaver wrote: - -1 to PEP8 (which is *not* universal in the Python community, as Fred pointed out; in particular, it makes choices which seem more appropriate to single-module code than namespaced-packages) +1 to Zope3 (and note that I have alreay moved there myself). That style is already documented; we should not need to expend any significant effort maintaining it. I would second Tres' reasoning, and the Zope3 styleguide is already second nature to me. - -- Martijn Pieters -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: http://firegpg.tuxfamily.org iD8DBQFG0FGi3xaj2GOvgP0RAuS6AJ9OeKJ+aLaoCdcrpthd3RyocsRFKgCgjh+y BHQHm1ie4tzF1ILo/NNjbTI= =YSNt -END PGP 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: RFC: Guide for maintaining software in the Zope repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: We have 100+ packages that make up what used to be distributed as Zope3. We have numerous more packages in svn.zope.org. Most of them are developed, released and distributed individually. We like to think this is a good thing (I certainly do). But currently we have a bit of a chaos [2]. It's not bad, but I fear without some guidance, it'll get worse. Christian Theune recently wrote a document [1] in which he outlined how we should get to a development process and what topics it should touch. This document is very hands-on and describes actions that should be taken to reach these goals. I've taken the liberty to jump ahead and write down some current practices: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt Thanks for drafting this document. A couple of comments (mostly niggles). - At then end of the last summary bullet under Repository layout, you say, Release tags shouldn't be committed to. I would say that is true *after* the release is announced. Sometimes it may be more convenient to modify the tagged code during the process of making the release (see below). - The changelog should include dates for each release, formatted consistently (ISO short form is likely best, as it is unambiguous). - Under Releasing Software, you specify what is to me a controversial rule: Increase the version number (in ``setup.py`` and elsewhere) on the trunk or the release branch to the *next* release. While I realize that many projects are doing this, I don't like it: I prefer that the trunk changelog contain an unreleased section for features / changes not tracked on the current release branch. In particular, I don't want to make it easy for somebody with a trunk or branch checkout to create a pseudo-release egg. In this case, speed kills, because sloppy release making punishes everybody downstream. I would therefore advocate keeping the 'version' tag on the trunk to something containing 'trunk' or 'unreleased'. Release branches should contain 'branch' in their version, except immediately before copying to a release tag. As an alternative (see above), copy the release tag and then change the version there. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0FPk+gerLs4ltQ4RAgn7AJ9BG0hcMn+cBkx6+1qW4bIeurlJQgCfa1l7 lVrgMfItaGX44N1fUBKBZwQ= =xvIa -END PGP 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] setting up application dependencies
Hey Benji, Thanks for this suggestion (the downloadable versions.cfg). I was thinking in the same direction after Jim briefly mentioned this possibility. For the Grok 0.10 release earlier this week I went with hardcoding it in setup.py (where necessary) to make sure it at least worked on Windows. This worked but indeed wasn't ideal. I only hit on the concept of a downloadable versions.cfg later on. We will definitely be experimenting with this. Thanks for your thoughts! Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Guide for maintaining software in the Zope repository
Tres, thanks for the comments! On 25 Aug 2007, at 18:08 , Tres Seaver wrote: Philipp von Weitershausen wrote: We have 100+ packages that make up what used to be distributed as Zope3. We have numerous more packages in svn.zope.org. Most of them are developed, released and distributed individually. We like to think this is a good thing (I certainly do). But currently we have a bit of a chaos [2]. It's not bad, but I fear without some guidance, it'll get worse. Christian Theune recently wrote a document [1] in which he outlined how we should get to a development process and what topics it should touch. This document is very hands-on and describes actions that should be taken to reach these goals. I've taken the liberty to jump ahead and write down some current practices: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/ maintaining-software.txt Thanks for drafting this document. A couple of comments (mostly niggles). - At then end of the last summary bullet under Repository layout, you say, Release tags shouldn't be committed to. I would say that is true *after* the release is announced. Sometimes it may be more convenient to modify the tagged code during the process of making the release (see below). - The changelog should include dates for each release, formatted consistently (ISO short form is likely best, as it is unambiguous). Two very good points. I fixed those in the document. - Under Releasing Software, you specify what is to me a controversial rule: Increase the version number (in ``setup.py`` and elsewhere) on the trunk or the release branch to the *next* release. While I realize that many projects are doing this, I don't like it: I prefer that the trunk changelog contain an unreleased section for features / changes not tracked on the current release branch. The point about the changelog is good. Whoever is making the release should create a new section (marked unreleased) in the changelog so that committers won't add their entries in an already released version's section. I've added that to the document as well (incl. an example). In particular, I don't want to make it easy for somebody with a trunk or branch checkout to create a pseudo-release egg. In this case, speed kills, because sloppy release making punishes everybody downstream. I would therefore advocate keeping the 'version' tag on the trunk to something containing 'trunk' or 'unreleased'. Release branches should contain 'branch' in their version, except immediately before copying to a release tag. As an alternative (see above), copy the release tag and then change the version there. This is not a bad suggestion. As I was explaining in my original email, I was mostly capturing our best practices so far. That doesn't mean the guide can't shape things for the better, but we should reach a consensus first. At least the guide is spurring awareness and discussion of these practices, which was part of the idea. I would suggest a mixture of our current practices and your suggestion: A release branch or the trunk's version statement in setup.py should contain both the version of the next anticipated release. As a marker for the fact that we're dealing with a development version, I suggest using the 'dev' marker that seems to be quite common around. So, on a branch or the trunk, setup.py should look like this: setup(version='1.1dev', ... whereas on a release tag, it should always look like this: setup(version='1.0', ... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
On Saturday 25 August 2007 06:31, Dieter Maurer wrote: I do not see lots of underscore rules, maybe because I disregard PEP 8... For me, the Java style (getMainType) is easier readable than the one prefered in the Python runtime library (get_main_type). Some people feel that theyCannotReadThisAndItShowsInASpellChecker and therefore can_read_and_spell_this_much_better is their choice, otherwise weWouldWriteAllSpokenLanguagesAndBooksThatWayForReadability. You could say that they come from a C background or that they are a little older. :-) Some other people say, e.g., those who come from Java background, that readingTheNamesLikeThisIsNotAProblemAtAll and they prefer that style. I'm sure we all heard the arguments pro and contra more times than we care to hear. Obviously, a visual perception differs from person to person. If a person has a difficulty reading getMainType(), they should not be forced to write get_main_type() in their Zope code for the sake of consistency which is in this particular issue non-existent. This is really the least important style issue. Best regards, -- Zvezdan Petkovic ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
On Saturday 25 August 2007 09:48, Benji York wrote: Andreas Jung wrote: Can someone please point out the major differences concerning Python code between PEP 8 and the Zope 3 style guide? The primary differences are in method, attribute, function, and variable names. PEP 8 specifies lower_case_with_underscores. Zope 3, more often than not (as noted by others, inconsistencies exists), follows these conventions: http://wiki.zope.org/zope3/ZopePythonNamingConventions specifies CamelCase for Public global variables (not exactly sure what all that encompasses) and lower_case_with_underscores for local variables. The same page prescribes mixedCase for module-level (non-factory) functions. http://wiki.zope.org/zope3/ClassesAttributesMethods specifies mixedCase for attributes and methods. FWIW, the Zope3 style guide on that wiki page states explicitly in the first paragraph that Python Style Guide is used for all issues that are not mentioned, and then continues to say that most of the code in Zope 3 so far uses CamelCase instead of names_as_this. The way I read this, it's most of the code so far uses, rather than all code must/should use. It's a *description* of the current state rather than the *prescription* to do it in CamelCase. Perhaps the intent to prescribe should have been stated explicitly, but currently it isn't, it's only nudged towards a new user. I also think this is the least worthy of style issues to pursue because it affects the reader's visual perception. All of us have different visual perceptions, some of us have bad eyes or some other reason to find one easier to read than other. Please see my other message in this thread on this. +1 for Benji's preference of PEP-8. Best regards, -- Zvezdan Petkovic ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] UPDATE: Guide for maintaining software in the Zope repository
Philipp von Weitershausen wrote: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt I've updated this document in a few minor ways today: * Incorporated our (new) policy on backward incompatible changes, based on Jim's earlier email to this list [1]. * Incorporated Tres feedback * Added examples for a README.txt and changelog. [1] http://mail.zope.org/pipermail/zope3-dev/2007-August/023366.html -- 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/archive%40mail-archive.com
