Re: [Zope3-dev] Zope 3.4, eggs and windows
Am Samstag, den 21.04.2007, 22:20 +0200 schrieb Martijn Faassen: Hi there, I have some questions about the Zope 3.4 release. My apologies if this information is already available somewhere else. I've just uploaded z3c.widget to download.zope.org/distribution, but ran into a new snag: it properly lists a whole bunch of dependencies in its setup.py that are currently Zope core packages, and thus post-3.3. I'm still developing against Zope 3.3 and using z3c.widget would therefore lead to a mix of Zope 3.3 and post 3.3 (3.4) packages in my installation. It's like to avoid this. Is there is a way to suppress the automatic download of dependencies for a particular egg in buildout? A manual hack is to upload a private version of z3c.widget somewhere that has a different dependency list and then refer to that. Instead of hacking, I could also decide to start relying on an eggified Zope 3.4 right away. I've heard some discussion though that makes me wonder whether an eggified release of Zope 3.4 will be fully cooked. I'm using the pre 3.4 eggs in some projects and they work fine. This leads to some questions: * I don't believe the 3.4 alpha eggs have been uploaded anywhere yet, right? Right. There was discussion about automation for that. I'm currently spending some time working on Zope bugs, but I might switch over to do those releases. Christian -- 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.4, eggs and windows
Hi, I took Martin's script and adapted it for this release. I took the listing of download.zope.org and gathered the names of all eggs that were available as 3.4dev eggs and am currently creating 3.4.0a1 eggs for those. It might be that these are not all eggs that should be build. However, doing an egg release for a package that is on zope.org is simple and quick now: Get the 'release-egg.sh' script from Zope3/trunk/releases/ and run it with 'release-egg.sh packagename version'. The script then - creates a tag for the release - checks out the release - changes the version parameter in setup.py - checks this in - runs setup.py sdist - uploads the tarball to download.zope.org I'll modify the script in the future if we get more complex requirements. Martin's original script already handled some cases that I didn't need right now, so I removed them for the moment (using a branch, ...) Christian -- 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.4, eggs and windows
The eggs are released now. I do not have updated the externals to the right location, the actual released code came from the Zope 3 trunk but is identical to the release. I noticed that after the fact that I made the release. :/ Updating the externals needs a little more effort to automate, but I'll do that later today. Christian Am Sonntag, den 22.04.2007, 12:38 +0200 schrieb Christian Theune: Hi, I took Martin's script and adapted it for this release. I took the listing of download.zope.org and gathered the names of all eggs that were available as 3.4dev eggs and am currently creating 3.4.0a1 eggs for those. It might be that these are not all eggs that should be build. However, doing an egg release for a package that is on zope.org is simple and quick now: Get the 'release-egg.sh' script from Zope3/trunk/releases/ and run it with 'release-egg.sh packagename version'. The script then - creates a tag for the release - checks out the release - changes the version parameter in setup.py - checks this in - runs setup.py sdist - uploads the tarball to download.zope.org I'll modify the script in the future if we get more complex requirements. Martin's original script already handled some cases that I didn't need right now, so I removed them for the moment (using a branch, ...) Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/ct%40gocept.com -- 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.4, eggs and windows
Christian Theune wrote: Hi, I took Martin's script and adapted it for this release. Heh, I've been doing open source for a few years now, but I still get a slight buzz when someone from outside my core constituency makes use of some code I've written. :) Glad it worked out. If you have changes that you think are generally useful, let me know. I didn't check in the original in a Plone repository yet, perhaps I should, or we could just keep one version in the Zope repo if that's easier. Martin ___ 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: Autoconfiguring a site.zcml
Hi Tres and Martijn. I apologize for the length of this post in advance. I have been spending a bit of time on app buildouts over the past days. What I have learned about some of this is that there are a couple of ways to configure apps with pluses and minuses. There are also major differences in time running buildouts depending on how you construct an app (since buildout checks against eggs in the main setup, dev eggs etc). To get a good sense of the acrobatics it is good to increase the verbosity of the output generated in buildout to -vv (you can add more v's to see more). In looking at the way I am developing, my goals are package reuse and thin glue in an app package (that is also the app egg) to bind packages to make an application consisting mostly of installation, security, testing and perhaps skinning. That said, I do not really want or care about organizing packages neatly under a single src folder to pull them together into a larger egg. To keep it simple, I just want to list the eggs I use in app part of my buildout. In the end it all about making sure that the code is able to connect. You are penalized for this approach in app buildouts since more small independent eggs (holding some generic functionality) with their own dependencies equals more checks. Being explicit like this increases the amount of time for the buildout to run, particularly if there are plenty of eggs with many dependencies. Think in numbers like 150 - 200+ eggs with zope and zope app - no exaggeration. Ok - now think again - that could be your time and not machine time working out that all dependencies are met. You start saying I like what computers can do and I can be patient while the checks are made. An approach that that leads to shorter app buildouts is to group packages under the main app setup.py. This is currently what fits with the development approach spelled out in the app recipe docs but it has downsides also. This is nice for speed in running a buildout but don't like the fact that the main setup has got to capture dependencies for the collection as a whole because you just a bigger egg with multiple packages where you still need to track down dependencies. True, some of these may be packages from external eggs you need to list, but probably more are packages that you have assembled within your app (that may be desirable to re-use) but where you have not been being explicit about the dependencies (since these are determined in an egg not a package). Personally, I don't want to take the time to try to pull the dependencies together in an app that is a collection of packages like this - since it is a chore not worthy of a human. A machine can do this better than I can (and it is welcome to the task!). Also, apps are prone to change - each change equals more time re-examining this over this again and again amidst a constantly changing landscape of package revisions - yuk. When you add that as a zope3/python developer you are mostly working at a package level, you realize that spelling dependencies with more granularity in an egg is much more attractive and just easier overall than figuring this out for an app with a cluster of packages afterwards (on top of how this all goes together with other external/namespace packages like zope, zope.app, z3c, zc etc, etc). I feel the same way about the site.zcml. In the initial docs on the app recipe, a smaller site.zcml is recommended since you can tuck most of the meat in your app configuration. In experimenting, the bottom line is it doesn't really matter where it is - because is really the same size regardless of where the pieces reside. So I have been considering - what am I really trying to do here - and how much grief do I want to encumber putting it all together. The semantics of having a large site.zcml that takes care of app configuration is not inconsistent with the fact that I am using the buildout to configure and build my app. So in the end I would be happy to consider a larger site.zcml that does the work of organizing includes to all packages in the app. And at the package level being left with just making the includes within it (such as including a browser or an ftest sub package) to complete the configuration tree. That said, I don't relish to time it will take to looking at ordering all of the includes in a site.zcml. It is tedious work and not fun at all. Here, this is still about dependency first. We need to make sure that as configuration is read, the app already knows enough for the next bit of configuration so it does not choke when run. Put it in the wrong order and your app will not understand what an adapter is, or a provider or one of your custom components. Unlike the comfort we had in automatically having all of the zope or zope app packages when we use zope we are now in the drivers seat to determine what we need by spelling it out. This provides power and
[Zope3-dev] Re: Autoconfiguring a site.zcml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Apr 22, 2007, at 10:32 AM, David Pratt wrote: ... In looking at the way I am developing, my goals are package reuse and thin glue in an app package (that is also the app egg) to bind packages to make an application consisting mostly of installation, security, testing and perhaps skinning. That said, I do not really want or care about organizing packages neatly under a single src folder to pull them together into a larger egg. To keep it simple, I just want to list the eggs I use in app part of my buildout. I wonder what you are trying to contrast here. Your goal of being able to just list eggs sounds reasonable. Who would disagree with it? ... You are penalized for this approach in app buildouts since more small independent eggs (holding some generic functionality) with their own dependencies equals more checks. What checks are you referring to? Being explicit like this Like what? I don't understand what the this is that you are referring to. increases the amount of time for the buildout to run, particularly if there are plenty of eggs with many dependencies. Think in numbers like 150 - 200+ eggs with zope and zope app - no exaggeration. Are you referring to Buildout's checking for new egg versions? Judicious use of the -N option can cut down on this a lot. ... An approach that that leads to shorter app buildouts is to group packages under the main app setup.py. This is currently what fits with the development approach spelled out in the app recipe docs but it has downsides also. I don't understand what you are referring to. Which app recipe are you referring to? This is nice for speed in running a buildout but don't like the fact that the main setup has got to capture dependencies for the collection as a whole because you just a bigger egg with multiple packages where you still need to track down dependencies. True, some of these may be packages from external eggs you need to list, but probably more are packages that you have assembled within your app (that may be desirable to re-use) but where you have not been being explicit about the dependencies (since these are determined in an egg not a package). Could you give some examples of what you're talking about. I'm trying to follow you but can't. You seem to be discussing whether dependencies should be listed in a setup file and suggesting that it somehow affects buildout performance. buildout performance isn't affected by *where* dependencies are defined. If your package has dependencies, then list them. This is othogonal to performance. Personally, I don't want to take the time to try to pull the dependencies together in an app that is a collection of packages like this - since it is a chore not worthy of a human.A machine can do this better than I can (and it is welcome to the task!). Also, apps are prone to change - each change equals more time re- examining this over this again and again amidst a constantly changing landscape of package revisions - yuk. Are you referring to Python dependencies or ZCML dependencies? If you are the author of a package, you should know what other packages you're using. You should know when this changes. In theory, determining these dependencies could be automated. No one has automated it yet. When you add that as a zope3/python developer you are mostly working at a package level, you realize that spelling dependencies with more granularity in an egg is much more attractive and just easier overall than figuring this out for an app with a cluster of packages afterwards (on top of how this all goes together with other external/namespace packages like zope, zope.app, z3c, zc etc, etc). I wish I knew what you were trying to say here. Are you saying that if A depends on B and B depends on C and A doesn't use C directly that A should not have to list C as a dependency? If so, I don't think anyone would disagree with you. I feel the same way about the site.zcml. In the initial docs on the app recipe, What app recipe. Please be specific. a smaller site.zcml is recommended since you can tuck most of the meat in your app configuration. In experimenting, the bottom line is it doesn't really matter where it is - because is really the same size regardless of where the pieces reside. So I have been considering - what am I really trying to do here - and how much grief do I want to encumber putting it all together. The semantics of having a large site.zcml that takes care of app configuration is not inconsistent with the fact that I am using the buildout to configure and build my app. So in the end I would be happy to consider a larger site.zcml that does the work of organizing includes to all packages in the app. And
Re: [Zope3-dev] Autoconfiguring a site.zcml
On Apr 21, 2007, at 11:06 AM, David Pratt wrote: I know attempting to do this manually is prone to errors if packages are not in the correct sequence or if you miss the configuration of a package. Any thoughts on this. Many thanks. Note that files can be ZCML included more than once. If a package depends on some other package, it should include it's configuration. 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/archive%40mail-archive.com
[Zope3-dev] Re: Autoconfiguring a site.zcml
On Apr 22, 2007, at 12:00 PM, Tres Seaver wrote: I don't think this is necessary. An egg that has ZCML should load the ZCML from other eggs it depends on. This means that these eggs have to be designed this way. Our override story is too weak to support this now, because the author of package C may make a configuration choice which is inappropriate for how C is used in B or A: we have no way to turn off such choices (we can shadow them, but not disable them). We really need a way to spell include the configuration from package 'A' except for the view registrations or include only the utilitiy registration for the 'IFoo' utiltiy from package 'B', or else we need to make the configurations much more fine-grained. Otherwise, we end up in a situation where using a package means accepting all of its configuration blindly; at that point, there is no win to moving the registrations out of Python code in the first place. You argument is correct, however, in practice, it usually doesn't matter. I would like to see a way to disable things in ZCML. There are a couple of proposals for doing this. I'd like to see one of them (preferably mind :) get implemented. 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/archive%40mail-archive.com
Re: [Zope3-dev] Re: Autoconfiguring a site.zcml
On Apr 22, 2007, at 10:32 AM, David Pratt wrote: ... In looking at the way I am developing, my goals are package reuse and thin glue in an app package (that is also the app egg) to bind packages to make an application consisting mostly of installation, security, testing and perhaps skinning. That said, I do not really want or care about organizing packages neatly under a single src folder to pull them together into a larger egg. To keep it simple, I just want to list the eggs I use in app part of my buildout. I wonder what you are trying to contrast here. Your goal of being able to just list eggs sounds reasonable. Who would disagree with it? ... You are penalized for this approach in app buildouts since more small independent eggs (holding some generic functionality) with their own dependencies equals more checks. What checks are you referring to? Being explicit like this Like what? I don't understand what the this is that you are referring to. increases the amount of time for the buildout to run, particularly if there are plenty of eggs with many dependencies. Think in numbers like 150 - 200+ eggs with zope and zope app - no exaggeration. Are you referring to Buildout's checking for new egg versions? Judicious use of the -N option can cut down on this a lot. ... An approach that that leads to shorter app buildouts is to group packages under the main app setup.py. This is currently what fits with the development approach spelled out in the app recipe docs but it has downsides also. I don't understand what you are referring to. Which app recipe are you referring to? This is nice for speed in running a buildout but don't like the fact that the main setup has got to capture dependencies for the collection as a whole because you just a bigger egg with multiple packages where you still need to track down dependencies. True, some of these may be packages from external eggs you need to list, but probably more are packages that you have assembled within your app (that may be desirable to re-use) but where you have not been being explicit about the dependencies (since these are determined in an egg not a package). Could you give some examples of what you're talking about. I'm trying to follow you but can't. You seem to be discussing whether dependencies should be listed in a setup file and suggesting that it somehow affects buildout performance. buildout performance isn't affected by *where* dependencies are defined. If your package has dependencies, then list them. This is othogonal to performance. Personally, I don't want to take the time to try to pull the dependencies together in an app that is a collection of packages like this - since it is a chore not worthy of a human.A machine can do this better than I can (and it is welcome to the task!). Also, apps are prone to change - each change equals more time re- examining this over this again and again amidst a constantly changing landscape of package revisions - yuk. Are you referring to Python dependencies or ZCML dependencies? If you are the author of a package, you should know what other packages you're using. You should know when this changes. In theory, determining these dependencies could be automated. No one has automated it yet. When you add that as a zope3/python developer you are mostly working at a package level, you realize that spelling dependencies with more granularity in an egg is much more attractive and just easier overall than figuring this out for an app with a cluster of packages afterwards (on top of how this all goes together with other external/namespace packages like zope, zope.app, z3c, zc etc, etc). I wish I knew what you were trying to say here. Are you saying that if A depends on B and B depends on C and A doesn't use C directly that A should not have to list C as a dependency? If so, I don't think anyone would disagree with you. I feel the same way about the site.zcml. In the initial docs on the app recipe, What app recipe. Please be specific. a smaller site.zcml is recommended since you can tuck most of the meat in your app configuration. In experimenting, the bottom line is it doesn't really matter where it is - because is really the same size regardless of where the pieces reside. So I have been considering - what am I really trying to do here - and how much grief do I want to encumber putting it all together. The semantics of having a large site.zcml that takes care of app configuration is not inconsistent with the fact that I am using the buildout to configure and build my app. So in the end I would be happy to consider a larger site.zcml that does the work of organizing includes to all packages in the app. And at the package level being left with just making the includes within it (such as including a browser or an ftest sub package) to complete the
[Zope3-dev] Re: Autoconfiguring a site.zcml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hello, Tres Seaver wrote: David Pratt wrote: On the basis that eggs spell out dependencies, I am thinking the inclusion of packages and their dependencies should be enough to dictate the sequence of inclusion for package configuration (and creation of the site.zcml) for the app buidout recipe. This could be a option to the current manual configuration. - -1. Configuration is *policy*; implicitly wiring in the default configuration for every egg on the path is not going to be an acceptable default. In the path? David didn't say in the path, did we? What about in the buildout? Since my buildout already says explicitly it wants egg foo, and egg foo needs egg bar, it is a major pain to have to specify the ZCML for bar manually. I don't think something being policy means it's automatically a bad candidate for automation. Information about the policy may after all be elsewhere in the system, for instance in a buildout.cfg. You don't see cases already where you want to use something from somebody else's package / egg, but don't want to accept every configuration choice they make? This is pretty hard to do if the system automagically wires in every pacakge's 'configure.zcml'. One of the big knocks against Zope2's 'product story was exactly this: there was no way to use a product without accepting its entire configuration. Presumably, the reason folks would use this recipe is to configure one or more of the same app. I know attempting to do this manually is prone to errors if packages are not in the correct sequence or if you miss the configuration of a package. Any thoughts on this. Many thanks. Not necessarily. There are really two kinds of packages in play here: libraryish packages, which supply mechanisms, and applicationish packages, which use the mechanism according to some policy. I would argue that the only things you can safely auto-include would be the 'meta.zcml', because it is policy-free. Reusable packages need to avoid imposing policy (they may *suggest* it, but they shouldn't insist). That's where we have the concept of overridable defaults. So the default should be to follow the suggestions, and there should be an option in the system to override this suggestion. There is not such place right now. The 'includeOverrides' directive is not expressive enough. I would cheer if somebody proposed writing a UI which introspcts packgaes for such suggestions, and allows the site manager to merge / override them to create an appropriate 'site.zcml'. Until then, I don't want package authors dictating to site managers. Who are these ZCML-using site managers you are speaking of? Anyway, are you saying you want some form of ZCML UI to be created before *any* automation can be implemented? Asking for the creation of a UI on the Zope 3 mailing list is paramount to waiting forever... *I* am the user I'm talking about: I want to be able to use others' components without swallowing whole their configuration choices; today, that means copying and modifying their 'configure.zcml' files. If you never automate policy, you'll be writing a lot of stuff by hand. That may be fine for you, but I myself would prefer to write less boring code and focus on more interesting problems. Automation which is hard to understand and override is the source of the Z shaped learning curve which plagued Zope2; it also plagues other convenience-oriented frameworks outside of Zopeland. 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 iD8DBQFGK4lm+gerLs4ltQ4RApoUAJ4g8t3xOSqAsIAcIawKy0xwgYrBqACeKoxJ 2Bq3bKeJZkT+sf/bxx5UUMQ= =TbFf -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] Getting 403 error from download.zope.org
Any idea what is happening with the site? Getting distribution for zope.app.zptpage Error: Can't download http://download.zope.org/distribution/zope.app.zptpage-3.4.0a1.tar.gz: 403 Forbidden Many thanks, Regards, David ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Getting 403 error from download.zope.org
Am Sonntag, den 22.04.2007, 15:11 -0400 schrieb Benji York: David Pratt wrote: Any idea what is happening with the site? Getting distribution for zope.app.zptpage Error: Can't download http://download.zope.org/distribution/zope.app.zptpage-3.4.0a1.tar.gz: 403 Forbidden That file isn't world-readable. scp (appears to be) using the file permissions as they are on the uploading file system. We need some way to guarantee that the resulting permissions are such that files placed in /distribution/ will be accessible. (Someone who has sudo on that machine will have to fix those permissions, I can't.) A chmod in a cron job is the best idea I have. Others? Gnarf. Right. That's my fault. My personal settings are user/group readable on my machine and scp blindly takes over those files. IMHO tweaking the masks on the target system could help, but I have no idea. Christian -- 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
