Re: [Zope3-dev] System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
Marius Gedminas wrote: * distros splitting the Python profiler into a separate package due to licencing problems, with a helpful stub that prints an informational message (go apt-get install python-profiler) instead of raising ImportError. On this one, I raised it with the package maintainer and I think this is now fixed... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Splitting package configuration
Hi everyone, I built my first Zope 3 instance with buildout yesterday. After I got an initial version working, I found it pretty lame to use zope.app.zcmlfiles. With zope.app.zcmlfiles I had 100 eggs without it 84 eggs (this is somewhat project-specific.) However, I had to add several unneeded dependencies, because the main configure.zcml of a package usually also includes the browser configure.zcml. For example, I have a dependency on zope.app.form, just because zope.app.securitypolicy (and other packages) create old-style forms. In fact, I do not even use anything declared in IDefaultBrowserLayer, so any browser configure.zcml is totally overhead for in this case. In fact, anyone creating a new skin from scratch will want to avoid the same overhead. I think the solution can be very simple and be effectively backward-compatible for most cases: 1. Do not include the browser configure.zcml files in the main configure.zcml of that package. 2. (a) If the package has a SETUP.cfg and package-configure.zcml, then add the browser configure.zcml include to that package-configure.zcml. (b) If the package is currently loaded via zope.app.zcmlfiles's configure.zcml, then we will add the browser configure.zcml there. This solution would not be fully backward-compatible with people including package configure.zcml files manually. I think this is okay, since people often do not even want the browser stuff. A fully backward solution would be to put all the generic package configuration in a new ZCML file and combine them both in configure.zcml. However, I find that solution very undesirable, so I hope noone will like it either. :-) I would like to get this change started as soon as possible to make it work for Zope 3.4. If noone objects, I will start with this in a few days. 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/archive%40mail-archive.com
Re: [Zope3-dev] Splitting package configuration
On 5/23/07, Stephan Richter [EMAIL PROTECTED] wrote: This solution would not be fully backward-compatible with people including package configure.zcml files manually. I think this is okay, since people often do not even want the browser stuff. That's hard to predict; some do, some don't, I don't know where most happens to fall. A fully backward solution would be to put all the generic package configuration in a new ZCML file and combine them both in configure.zcml. However, I find that solution very undesirable, so I hope noone will like it either. :-) I don't like that, but I don't think it's avoidable. I would like to get this change started as soon as possible to make it work for Zope 3.4. If noone objects, I will start with this in a few days. 3.4 is never going to be released, is it? That might bother some people (though not me). -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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: Splitting package configuration
On May 23, 2007, at 12:35 PM, Tres Seaver wrote: I don't know what is blocking a 3.4 release. AFAIK, eggification is on the roadmap for 3.5, right? So we should be focused on stabilizing the last zpkg build, while still allowing the eggified / broken-out project model to move forward. That's my understanding too. 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: Splitting package configuration
On 5/23/07, Tres Seaver [EMAIL PROTECTED] wrote: Hmm, the use case for slugs was to support application with separately installed extensions; Fred, I think your view is prejudiced by the fact that you don't have any need for pluggability / extensibility. Possibly so. I'm certainly not building apps where drop-in extensibility is as helpful as others are. Stephan is arguing for finer-grained configurations, which is likely to be better for reuse, at the cost of *reduced* convenience. Yes, and that's fine for me. What I consider an issue is that changing the semantics of include package=zope.foo.package/ is a change to the package's public interface. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
On Wed, May 23, 2007 at 09:37:33AM +0200, Philipp von Weitershausen wrote: Marius Gedminas wrote: On Mon, May 21, 2007 at 10:44:47AM -0400, Jim Fulton wrote: On May 21, 2007, at 1:39 AM, Martijn Pieters wrote: Come again? Using the system python when developing has always been fine; No. It has never been fine for any aspect of development. If you develop with your system Python and deploy with a custom environment, then you've added a variable that is different between the two environments. Also, system Python's are often hobbled in ways that hurt development. I sometimes get really weird error reports that are traced to system Pythons. People who report problems to me that result from using a system Python make me angry and make me want to not answer their questions or otherwise help them any more. I'd love to hear some anecdotes about this. The ones I know about: * distros releasing newer point versions of Python with security fixes (cgi.FieldStorage) that break Zope 3 I consider that a major show-stopper. An innocent apt-get upgrade pulls in Python 2.4.4c0 and all of a sudden all your Zope apps break! Well not mine, I use self-compiled Pythons for my production servers... Was that a security update to a released version? Otherwise it's not so innocent for a production system;) btw, in future, it is planned to integrate the zope3 tests with autopkgtest, http://packages.debian.org/unstable/devel/autopkgtest. Which should mean that this kind of breakage will happen less as autopkgtest basically is running the tests of installed packages on installed packages. -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
