[Zope-dev] Re: AW: Re: Grok 0.11 released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Roger Ineichen wrote: >> Hi Tres >> >>> Whoever released those two eggs (the '.dev-r#' ones) need >>> to release "real" updated packages, and then grok 0.11.1 >>> should be released using them. >>> >>> DEATH TO FAUX PACKAGES! >> As far as I understand, this does not happen if you >> depend on a KGS, right? >> >> Does the grok release not use the KGS from Stephan? >> > > Not yet. We intend to look at that list at some point. Of course the KGS > probably doesn't contain recent enough packages to support the REST > changes. If the REST stuff depended on unreleased versions of upstream packages, then it should not have been merged until those packages were released in an acceptable (non-snapshot) form. > The other problem with KGS is that I absolutely want to fix lists of > packages into Grok itself and never rely on any system that can cause > the list of packages that could be updated. KGS will get bugfix > releases. These will inevitably break something on occassion. I have no > idea what will happen once 3.5 packages will start to appear, either. A KGS needs to have the following properties: - The "generation zero" of any KGS is an empty set of revisions. - By default, any revision N of a KGS starts out as a "draft" version which is an empty layer over version N-1. Changes to the draft then shadow any versions in the prior revision. - Once "finalized" / "published", a given revision of a KGS can *never* be changed. - Any KGS can be derived from the published version of another KGS, with additions of new distributions / versions and updates of versions for underlying distributions. - In conjunction with a "find-links" site which promises never to remove any distribution which has been included in a published revision of a KGS, the current 'version.cfg' (and workalike) files are sufficient to establish a KGS. Without that promise, however, those files can't be considered as defining a KGS. Therefore, - Given that all distribution versions mentioned in a KGS are stored at a trusted / reliable URL, any immutable KGS revision can be trivially transformed into a PyPI package index: each distribution will have exactly one allowed version, which will point to a single URL on a reliable server. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNS+v+gerLs4ltQ4RAl/rAJ9lDeB9nOXGab+/uAithNjeMeREkwCgguHF 5qA0vftURPPCW7SR2yZVTmk= =NBMc -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/trunk/setup.py This package doesn't just work with any versin of zope.i18nmessageid, it needs
Philipp von Weitershausen wrote: [snip] Only the '==' qualifier in setup.py is a bad idea because it locks you down. Other qualifiers are actually quite necessary sometimes. Agreed. In addition hopefully at some point we'll get 'or' support, so you can use == again: zope.i18nmessageid >= 3.4.2 or zope.i18nmessageid == 3.4.2 A tool like buildout can then choose to pick the more specific version indicators if there is nothing else overriding it. This would solve a ton of problems we're currently trying to use external indexes for (either Grok's list or KGS). Once this is in place, the only use for an external package index would be to make sure no releases are ever deleted, or changed without updating the version number. I know I sound like a broken record on this, but fixing versions in indexes is really the wrong place: the version requirements should be in the releases themselves. Any index approach will need as many indexes as there are frameworks and applications. There just needs to be a way to override them from outer dependencies. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: Re: Grok 0.11 released!
Philipp von Weitershausen wrote: [snip] So you're telling me that in order to define my own KGS (which anybody should do for a serious project), I'll have to start deploying my own index. For each project? I think Grok should be using KGS by simply taking snapshots of it sometimes and then building an own list of absolutely fixed versions from it. There are a lot of problems not solved yet concerning fixing versions in any solution I've seen so far. Grok can fix a single list right now, but what if we release megrok.genshi which relies on a particular version of Genshi? If you are using that in your application, you'll have to add it and all its dependencies to buildout.cfg manually, *or* megrok.genshi will have to release its own versions.cfg somewhere on some website that we then also ask people to extend. Anyway, all this requires quite a bit of overhead and typing. If we relied on KGS, we could release a fixed version of megrok.genshi, but what to do when it needs an update? We don't want to force all users to update - this needs to be under the application developer's control. KGS is good for integration tests and developing against, but I don't see it as a good solution for releasing against. I'm still convinced the real solution involves storing fixed version number requirements where they belong: in the packages themselves (with an 'or' story in setup.py). This isn't perfect either, as the packages may disappear from the cheeseshop, so a separate index like KGS would be desirable in combination with this approach. I want a solution where someone can say: "I want to rely on foo 0.7", and then it'll get that and a fixed version of all its dependencies (unless it's explicitly overridden). I want people to be able to say this with a minimal amount of work (no need to set up and maintain your own index) and no risk at all that later on suddenly you'll be getting different versions. Not even bugfixes. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: Re: Grok 0.11 released!
Roger Ineichen wrote: Hi Tres Whoever released those two eggs (the '.dev-r#' ones) need to release "real" updated packages, and then grok 0.11.1 should be released using them. DEATH TO FAUX PACKAGES! As far as I understand, this does not happen if you depend on a KGS, right? Does the grok release not use the KGS from Stephan? Not yet. We intend to look at that list at some point. Of course the KGS probably doesn't contain recent enough packages to support the REST changes. The other problem with KGS is that I absolutely want to fix lists of packages into Grok itself and never rely on any system that can cause the list of packages that could be updated. KGS will get bugfix releases. These will inevitably break something on occassion. I have no idea what will happen once 3.5 packages will start to appear, either. Regarsd, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: AW: Re: Grok 0.11 released!
Stephan Richter wrote: On Friday 09 November 2007, Lennart Regebro wrote: On Nov 9, 2007 4:06 PM, Roger Ineichen <[EMAIL PROTECTED]> wrote: Create our own locked down index? I think so because, Surely there must be a way to say "I want to use THAT KGS over there. Except for this module, that should hav this version. And of course, all these bunch of eggs which isn't dfined in that KGS at all". Unfortunately, this is not how the index works in setuptools. Which is why I think the index-page KGS solution is largely unusable for the projects I work in. :-/ Can you please also confirm something for me - if I use the Zope KGS index page, and I also need a package from the Cheese Shop, and the Cheese Shop contains newer (not-good) versions of packages that are also in the KGS index, will setuptools/buildout use the one from the KGS without a narrow version spec in my egg dependencies? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: bug in ZopePageTemplate.py?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Hi Guys, > > Can you remember why you added the following line to ZopePageTemplate.py? > > content_type = 'text/html' > > It seems to arbitarily lock new page templates (or subclasses of them) > into text/html mode. > > MailTemplates subclass ZopePageTemplate and expect to be text/plain by > default... That code is there only when reading from the default content, right? And that file is *definitely* 'text/html'. Why don't you just override it at class level in the subclass? For instance, override '__init__' to read your file before calling the 'super' version, and pass its contents through as 'text', along with your desired 'content_type'. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNNvE+gerLs4ltQ4RAuOcAKDN/dv+ADtX3tZOpKFqH9AJ2GbKOwCfeyvZ rzHP8cn3/KF+OsMZxWzBvb4= =r2oa -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Hivurt blog
Mikhail Kashkin wrote: Hi, every new day Hivurt is closer to alfa release, we are doing a lot of job to cleanup source code and adding new functionality. To inform people around I has open blog http://hivurt.wordpress.com/. This is place where we will publish news, screenshots, tips, answers about university and everything. You are welcome! Many people asking me about license. Hivurt and every part of its code is under ZPL! P.S. But until we move to new Hivurt-only code repository inside http://code.keysolutions.ru/svn/ still some code under GPL -- Mikhail Kashkin, skype:mkashkin, jabber:[EMAIL PROTECTED] Key Solutions (http://keysolutions.ru/) Offshore Zope3 development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
AW: AW: [Zope-dev] RFC: Packages should load configuration they depend upon
Hi Philipp > Betreff: Re: AW: [Zope-dev] RFC: Packages should load > configuration they depend upon > > On 9 Nov 2007, at 20:15 , Roger Ineichen wrote: > >> Betreff: [Zope-dev] RFC: Packages should load configuration they > >> depend upon > >> > >> http://wiki.zope.org/zope3/PackagesShouldLoadConfigurationThey > >> DependUpon > >> > >> Comments appreciated. Otherwise, silence is treated as assent. > >> > >> I'm planning on starting with this tomorrow as part of the Boring > >> Sprint we're having in Tübingen right now. > > > > Do I get this right, are you proposing moving everything from > > ftesting.zcml to configure.zcml? > > > > Or only a subset of ftesting.zcml? > > Only the stuff that's an intrinsic dependency of the > package's configuration. ftesting.zcml will always contain > more directives that are specific to the functional tests > (e.g. configuring a security policy, test principals, etc.) Holy grail, if you like to do this, this means you need to look carfully if a package not only has a dependency to a apckage because it needs a interface or the configured implementation. We have a lot of dependency to package because we depend on interfaces and not on the implementation. Right now it is Ok, if we skip the configuration. But If you will configure them by default in zcml. MY next step whould be to move the interfaces out of the packages if I don't need the configured component rather then override it. Becaues override.zcml sucks. e.g. I'm useing zope.app.folder.Folder as a super class but I never use the Folder as component. etc. etc. In my point of view I whould say this is not possible at all. Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: AW: [Zope-dev] RFC: Packages should load configuration they depend upon
On 9 Nov 2007, at 20:15 , Roger Ineichen wrote: Betreff: [Zope-dev] RFC: Packages should load configuration they depend upon http://wiki.zope.org/zope3/PackagesShouldLoadConfigurationThey DependUpon Comments appreciated. Otherwise, silence is treated as assent. I'm planning on starting with this tomorrow as part of the Boring Sprint we're having in Tübingen right now. Do I get this right, are you proposing moving everything from ftesting.zcml to configure.zcml? Or only a subset of ftesting.zcml? Only the stuff that's an intrinsic dependency of the package's configuration. ftesting.zcml will always contain more directives that are specific to the functional tests (e.g. configuring a security policy, test principals, etc.) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
AW: [Zope-dev] RFC: Packages should load configuration they depend upon
Hi Philipp > Betreff: [Zope-dev] RFC: Packages should load configuration > they depend upon > > http://wiki.zope.org/zope3/PackagesShouldLoadConfigurationThey > DependUpon > > Comments appreciated. Otherwise, silence is treated as assent. > > I'm planning on starting with this tomorrow as part of the > Boring Sprint we're having in Tübingen right now. Do I get this right, are you proposing moving everything from ftesting.zcml to configure.zcml? Or only a subset of ftesting.zcml? Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/branches/3.4/CHANGES.txt Bring over changes from the trunk
On Friday 09 November 2007, Chris McDonough wrote: > We should probably try to fix easy_install so that it can use layered > indexes (like apt and yum do). Yep, that would be ideal. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/branches/3.4/CHANGES.txt Bring over changes from the trunk
We should probably try to fix easy_install so that it can use layered indexes (like apt and yum do). - C On Nov 9, 2007, at 11:11 AM, Lennart Regebro wrote: On Nov 9, 2007 5:02 PM, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Yeah, but other packages in the current KGS have already been converted to use zope.securitypolicy, so reverting the split-up would cause more trouble than I thought it would've fixed. Ah, so if this is done, the next KGS version can't be easily based on the current one, is that correct? The split was done at the wrong time, but it can go into 3.4 even though it strictly breaks the "no new features during beta"-rule, right? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RFC: Packages should load configuration they depend upon
http://wiki.zope.org/zope3/PackagesShouldLoadConfigurationTheyDependUpon Comments appreciated. Otherwise, silence is treated as assent. I'm planning on starting with this tomorrow as part of the Boring Sprint we're having in Tübingen right now. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/branches/3.4/CHANGES.txt Bring over changes from the trunk
On 9 Nov 2007, at 17:11 , Lennart Regebro wrote: On Nov 9, 2007 5:02 PM, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Yeah, but other packages in the current KGS have already been converted to use zope.securitypolicy, so reverting the split-up would cause more trouble than I thought it would've fixed. Ah, so if this is done, the next KGS version can't be easily based on the current one, is that correct? I suppose you mean that the KGS couldn't have easily been updated to use that new version of zope.app.securitypolicy, in which case you're right :). The split was done at the wrong time, but it can go into 3.4 even though it strictly breaks the "no new features during beta"-rule, right? Right. I thought I could fix that mistake, but I was too ambitious. It's not a big deal, but I thought I could root out some BBB problems by doing it the Right Way. Thankfully Stephan reminded me that it wasn't that easy. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/branches/3.4/CHANGES.txt Bring over changes from the trunk
On Nov 9, 2007 5:02 PM, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Yeah, but other packages in the current KGS have already been > converted to use zope.securitypolicy, so reverting the split-up would > cause more trouble than I thought it would've fixed. Ah, so if this is done, the next KGS version can't be easily based on the current one, is that correct? The split was done at the wrong time, but it can go into 3.4 even though it strictly breaks the "no new features during beta"-rule, right? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/branches/3.4/CHANGES.txt Bring over changes from the trunk
On 9 Nov 2007, at 16:51 , Lennart Regebro wrote: On Nov 9, 2007 4:06 PM, Stephan Richter <[EMAIL PROTECTED]> wrote: On Friday 09 November 2007, Philipp von Weitershausen wrote: -Version 3.4.0 (2007/9/25) -- +- Reverted the premature split away of core components to + zope.securitypolicy. Switch to zope.app.securitypolicy 3.5.x or + higher if you want the split. I want more discussion on this! This breaks the entire KGS now! Hang on isn't the KGS a list of versions that work together? How can then any sort of change break the KGS? Only a re-release of an old version number (which is wrong in itself) should be able to do that. I'm confused now. Yeah, but other packages in the current KGS have already been converted to use zope.securitypolicy, so reverting the split-up would cause more trouble than I thought it would've fixed. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Grok 0.11 released!
On Friday 09 November 2007, Lennart Regebro wrote: > On Nov 9, 2007 4:34 PM, Philipp von Weitershausen > > <[EMAIL PROTECTED]> wrote: > > Those are exactly the problems with the locked down index: > > > > * You can always use *more* packages but you'll have to lock them down > > yourself, can't use another KGS for those > > Could we create a grok KGS which is generated by a python-script, that > takes the correct zope3 KGS as a base? With a little bit more software, yes. > > * You cannot say "I know the KGS prefers zope.frobnaz 1.2.3, but I > > deliberately want to upgrade to zope.frobnaz 2.0.2". It won't work > > because the index simply doesn't expose the 2.0.2 version of > > zope.frobnaz. > > This needs to be fixed in setup tools some time in the future, then, > because it will severly limit the usablility of a KGSs if you can't > use this. You very often need to upgrade one package... Right, I agree. But there are solutions. You can use find-links to get a newer version. The beautiful thing about not nailing versions is that you can overwrite what the index says. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/branches/3.4/CHANGES.txt Bring over changes from the trunk
On Nov 9, 2007 4:06 PM, Stephan Richter <[EMAIL PROTECTED]> wrote: > On Friday 09 November 2007, Philipp von Weitershausen wrote: > > -Version 3.4.0 (2007/9/25) > > -- > > +- Reverted the premature split away of core components to > > + zope.securitypolicy. Switch to zope.app.securitypolicy 3.5.x or > > + higher if you want the split. > > I want more discussion on this! This breaks the entire KGS now! Hang on isn't the KGS a list of versions that work together? How can then any sort of change break the KGS? Only a re-release of an old version number (which is wrong in itself) should be able to do that. I'm confused now. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: AW: Re: Grok 0.11 released!
On Friday 09 November 2007, Philipp von Weitershausen wrote: > I think we're now quite aware of that problem. Hence we need the KGS. > But I'm questioning the implementation using a "locked down index". What's the alternative? Nailing versions is not it for me, which by the way you can do with http://download.zope.org/Zope3.4/versions.cfg already. Can you specify multiple version URLs? Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Grok 0.11 released!
On Nov 9, 2007 4:34 PM, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Those are exactly the problems with the locked down index: > > * You can always use *more* packages but you'll have to lock them down > yourself, can't use another KGS for those Could we create a grok KGS which is generated by a python-script, that takes the correct zope3 KGS as a base? > * You cannot say "I know the KGS prefers zope.frobnaz 1.2.3, but I > deliberately want to upgrade to zope.frobnaz 2.0.2". It won't work > because the index simply doesn't expose the 2.0.2 version of zope.frobnaz. This needs to be fixed in setup tools some time in the future, then, because it will severly limit the usablility of a KGSs if you can't use this. You very often need to upgrade one package... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Grok 0.11 released!
On Friday 09 November 2007, Philipp von Weitershausen wrote: > Those are exactly the problems with the locked down index: > > * You can always use *more* packages but you'll have to lock them down > yourself, can't use another KGS for those But this is a limitation of setuptools. I think this could be solved using find-links for now. > * You cannot say "I know the KGS prefers zope.frobnaz 1.2.3, but I > deliberately want to upgrade to zope.frobnaz 2.0.2". It won't work > because the index simply doesn't expose the 2.0.2 version of zope.frobnaz. You can use find-links and point to the new location. > So the "locked down index" doesn't support two important use cases. And > building your own index isn't really a solution, IMO. The average > cavemen programmer won't do that... The problem here is that setuptools is too immature to handle those cases properly. We will have to write a lot more software to do this correctly. The KGS index approach was just something that would give us sanity with very little new software. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: AW: Re: Grok 0.11 released!
Roger Ineichen wrote: Before KGS there was no concept for keep the eggs in sync. Each project has to do it by itself. KGS at least is something that helps to manage the zope eggs. Everything outside this has to be done by the release manager of the project. And before the KGS, the cheesshop was nothing else then a different concept for get packages. The reason why is; Fixing revision numbers in packages does not work!!! Fixing version will make it impossible to use it as base and mix other packge into a setup. Because of the potential conflicting packages you will mixin. I think we're now quite aware of that problem. Hence we need the KGS. But I'm questioning the implementation using a "locked down index". ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Grok 0.11 released!
Lennart Regebro wrote: On Nov 9, 2007 4:06 PM, Roger Ineichen <[EMAIL PROTECTED]> wrote: Create our own locked down index? I think so because, Surely there must be a way to say "I want to use THAT KGS over there. Except for this module, that should hav this version. And of course, all these bunch of eggs which isn't dfined in that KGS at all". Because that's what we all need. So it must be possible, right? The KGS is just that, a Known Good Set. It must be possible to in your build out override a version here and add packages there? Those are exactly the problems with the locked down index: * You can always use *more* packages but you'll have to lock them down yourself, can't use another KGS for those * You cannot say "I know the KGS prefers zope.frobnaz 1.2.3, but I deliberately want to upgrade to zope.frobnaz 2.0.2". It won't work because the index simply doesn't expose the 2.0.2 version of zope.frobnaz. So the "locked down index" doesn't support two important use cases. And building your own index isn't really a solution, IMO. The average cavemen programmer won't do that... ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] AW: AW: Re: Grok 0.11 released!
On Friday 09 November 2007, Lennart Regebro wrote: > On Nov 9, 2007 4:06 PM, Roger Ineichen <[EMAIL PROTECTED]> wrote: > > > Create our own locked down index? > > > > I think so because, > > Surely there must be a way to say "I want to use THAT KGS over there. > Except for this module, that should hav this version. And of course, > all these bunch of eggs which isn't dfined in that KGS at all". Unfortunately, this is not how the index works in setuptools. > Because that's what we all need. So it must be possible, right? The > KGS is just that, a Known Good Set. It must be possible to in your > build out override a version here and add packages there? So the way to do this is to use versions.cfg from the KGS, which locks to the latest version of all packages in the KGS; since the URL can be pointed directly to the KGS server, you will get all the updates too. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/trunk/setup.py This package doesn't just work with any versin of zope.i18nmessageid, it needs
Stephan Richter wrote: On Friday 09 November 2007, Philipp von Weitershausen wrote: Modified: zope.app.securitypolicy/trunk/setup.py === --- zope.app.securitypolicy/trunk/setup.py 2007-11-09 13:08:59 UTC (rev 81634) +++ zope.app.securitypolicy/trunk/setup.py 2007-11-09 14:52:52 UTC (rev 81635) @@ -58,7 +58,7 @@ 'zope.configuration', 'zope.exceptions', 'zope.i18n', - 'zope.i18nmessageid', + 'zope.i18nmessageid >= 3.4.2', 'zope.interface', 'zope.location', 'zope.schema', Please let's stop putting versions into setup.py. This is a really bad idea, since it will make it very hard to work with in different project with different version requirements. Only the '==' qualifier in setup.py is a bad idea because it locks you down. Other qualifiers are actually quite necessary sometimes. In this case, for instance, we *need* the >= qualifier because zope.app.securitypolicy won't work with just any version of zope.i18nmessageid. It needs at least version 3.4.2 because that one introduced the ZopeMessageFactory object which zope.app.securitypolicy wants to import. Such considerations must always be made when you add a feature to package A, and then use that new feature in package B. Package B must then require at least that new version of package A. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] AW: AW: Re: Grok 0.11 released!
On Nov 9, 2007 4:06 PM, Roger Ineichen <[EMAIL PROTECTED]> wrote: > > Create our own locked down index? > > I think so because, Surely there must be a way to say "I want to use THAT KGS over there. Except for this module, that should hav this version. And of course, all these bunch of eggs which isn't dfined in that KGS at all". Because that's what we all need. So it must be possible, right? The KGS is just that, a Known Good Set. It must be possible to in your build out override a version here and add packages there? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: Re: Grok 0.11 released!
Stephan Richter wrote: On Friday 09 November 2007, Philipp von Weitershausen wrote: It can't because you guys broke a dozen packages when you split up some of the zope.app.* packages. I'm going to fix this now. Can we stop pointing fingers, please? Sorry for not sugar coating the facts. I gladly will stop pointing fingers when you guys fix the bugs that you introduced and have been made aware of, e.g. https://bugs.launchpad.net/zope3/+bug/158743. Not to worry now, I finally found the time to do it myself at the Boring Sprint now. I just spent 3-4 man-weeks to get the packages to a decent state, produce the KGS and write tools to make the entire process a little saner. Certainly not a mess that I started. Also, I have a couple of beefs with the "locked down index" approach to the KGS. For instance, if we use the Zope 3.4.x KGS, how would we lock down the version of the grok egg? Or simplejson, z3c.flashmessage and all the other Grok-specific dependencies? Create our own locked down index? I don't think so. For all packages living at svn.zope.org, the KGS is open and people can submit additions, as I offered in a recent zope-dev mail. (I wonder whether anyone read it.) As for other packages, you have two choices: (1) Fix the versions in the [version] section of buildout. (2) Derive a new KGS based on the Zope 3.4 one. When Jim and I discussed the KGS and how to implement it initially, we had the second solution in mind. In fact, we talked in particular about grok as an example. Implementing support for (2) should be pretty simple. You simply have to enhance the zc.mirrorcheeseshopslashsimple code to accept multiple controlled-pages.cfg files. This should take about 30 mins. The versions.cfg file loaded from HTTP works now. If you want some of the testing comforts that I have enjoyed, then you need to adjust zope.release to handle multiple controlled-packages.cfg files as well. This is an overall easy task and getting the index online is also pretty straightforward. I use the following crontab configuration: [EMAIL PROTECTED] * * * * * /home/srichter/mirror-tool/bin/generate-controlled-pages /var/www/download.zope.org/zop e3.4 * * * * * /home/srichter/mirror-tool/bin/update-simple-mirror /var/www/download.zope.org/zope3.4 So you're telling me that in order to define my own KGS (which anybody should do for a serious project), I'll have to start deploying my own index. For each project? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] AW: AW: Re: Grok 0.11 released!
Hi Philipp > Betreff: Re: AW: Re: Grok 0.11 released! > > Stephan Richter wrote: > > On Friday 09 November 2007, Roger Ineichen wrote: > >> Hi Tres > >> > >>> Whoever released those two eggs (the '.dev-r#' ones) need to > >>> release "real" updated packages, and then grok 0.11.1 should be > >>> released using them. > >>> > >>> DEATH TO FAUX PACKAGES! > >> As far as I understand, this does not happen if you depend > on a KGS, > >> right? > >> > >> Does the grok release not use the KGS from Stephan? > > > > I agree with Roger, Grok should use the KGS and all will be > fine. ;-) > > It can't because you guys broke a dozen packages when you > split up some of the zope.app.* packages. I'm going to fix this now. > > > Also, I have a couple of beefs with the "locked down index" > approach to > the KGS. For instance, if we use the Zope 3.4.x KGS, how > would we lock > down the version of the grok egg? Or simplejson, z3c.flashmessage and > all the other Grok-specific dependencies? Create our own locked down > index? I don't think so. I think so because, Before KGS there was no concept for keep the eggs in sync. Each project has to do it by itself. KGS at least is something that helps to manage the zope eggs. Everything outside this has to be done by the release manager of the project. And before the KGS, the cheesshop was nothing else then a different concept for get packages. The reason why is; Fixing revision numbers in packages does not work!!! Fixing version will make it impossible to use it as base and mix other packge into a setup. Because of the potential conflicting packages you will mixin. e.g. if a package foo-0.1 use bar-0.1 and bar get update to bar-0.2 and breaks, you can update bar to bar-0.3 and make it work again. If you fix the version in package foo-0.1 only to use bar-0.1 because the broken bar-0.2 you will get in trouble. Because foo-0.1 works with bar-0.1 and bar-0.3. The way to go is: You can use a KGS and define that you use foo-0.1 and bar-0.2 or foo-0.1 and bar-0.2. Agan, if you try to fix this in the egg itself, you get blocked sooner or later. I think the next step for KGS is to define more KGS packages. This will make sure that we have a better controll of what is working with what. Note, we lost all this since the eggs do not have a realation to the subsversion version numbers. The Subversion did ensure that for a specific timestamp everything (in the trunk) was working with each other. That's history and now a part of the release process. But the good thing about eggs and the KGS now is, that we are able to define the working set for packages outside the Zope trunk too. Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/branches/3.4/ Revert the splitup of zope.app.securitypolicy in the stable 3.4.x line (it will be confined
On Friday 09 November 2007, Philipp von Weitershausen wrote: > Revert the splitup of zope.app.securitypolicy in the stable 3.4.x line > (it will be confined to the trunk/3.5.x line). We're doing this by creating > the 3.4.x branch based on the last working release, 3.4.0. Please do not do this!! All packages in the KGS have been adjusted! Just fix the broken things! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/branches/3.4/CHANGES.txt Bring over changes from the trunk
On Friday 09 November 2007, Philipp von Weitershausen wrote: > -Version 3.4.0 (2007/9/25) > -- > +- Reverted the premature split away of core components to > + zope.securitypolicy. Switch to zope.app.securitypolicy 3.5.x or > + higher if you want the split. I want more discussion on this! This breaks the entire KGS now! ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: zope.app.securitypolicy/trunk/setup.py This package doesn't just work with any versin of zope.i18nmessageid, it needs
On Friday 09 November 2007, Philipp von Weitershausen wrote: > Modified: zope.app.securitypolicy/trunk/setup.py > === > --- zope.app.securitypolicy/trunk/setup.py 2007-11-09 13:08:59 UTC > (rev 81634) +++ zope.app.securitypolicy/trunk/setup.py 2007-11-09 > 14:52:52 UTC (rev 81635) @@ -58,7 +58,7 @@ > 'zope.configuration', > 'zope.exceptions', > 'zope.i18n', > - 'zope.i18nmessageid', > + 'zope.i18nmessageid >= 3.4.2', > 'zope.interface', > 'zope.location', > 'zope.schema', Please let's stop putting versions into setup.py. This is a really bad idea, since it will make it very hard to work with in different project with different version requirements. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: Re: Grok 0.11 released!
On Friday 09 November 2007, Philipp von Weitershausen wrote: > It can't because you guys broke a dozen packages when you split up some > of the zope.app.* packages. I'm going to fix this now. Can we stop pointing fingers, please? I just spent 3-4 man-weeks to get the packages to a decent state, produce the KGS and write tools to make the entire process a little saner. Certainly not a mess that I started. > Also, I have a couple of beefs with the "locked down index" approach to > the KGS. For instance, if we use the Zope 3.4.x KGS, how would we lock > down the version of the grok egg? Or simplejson, z3c.flashmessage and > all the other Grok-specific dependencies? Create our own locked down > index? I don't think so. For all packages living at svn.zope.org, the KGS is open and people can submit additions, as I offered in a recent zope-dev mail. (I wonder whether anyone read it.) As for other packages, you have two choices: (1) Fix the versions in the [version] section of buildout. (2) Derive a new KGS based on the Zope 3.4 one. When Jim and I discussed the KGS and how to implement it initially, we had the second solution in mind. In fact, we talked in particular about grok as an example. Implementing support for (2) should be pretty simple. You simply have to enhance the zc.mirrorcheeseshopslashsimple code to accept multiple controlled-pages.cfg files. This should take about 30 mins. If you want some of the testing comforts that I have enjoyed, then you need to adjust zope.release to handle multiple controlled-packages.cfg files as well. This is an overall easy task and getting the index online is also pretty straightforward. I use the following crontab configuration: [EMAIL PROTECTED] * * * * * /home/srichter/mirror-tool/bin/generate-controlled-pages /var/www/download.zope.org/zop e3.4 * * * * * /home/srichter/mirror-tool/bin/update-simple-mirror /var/www/download.zope.org/zope3.4 Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: Re: Grok 0.11 released!
Stephan Richter wrote: On Friday 09 November 2007, Roger Ineichen wrote: Hi Tres Whoever released those two eggs (the '.dev-r#' ones) need to release "real" updated packages, and then grok 0.11.1 should be released using them. DEATH TO FAUX PACKAGES! As far as I understand, this does not happen if you depend on a KGS, right? Does the grok release not use the KGS from Stephan? I agree with Roger, Grok should use the KGS and all will be fine. ;-) It can't because you guys broke a dozen packages when you split up some of the zope.app.* packages. I'm going to fix this now. Also, I have a couple of beefs with the "locked down index" approach to the KGS. For instance, if we use the Zope 3.4.x KGS, how would we lock down the version of the grok egg? Or simplejson, z3c.flashmessage and all the other Grok-specific dependencies? Create our own locked down index? I don't think so. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: AW: [Zope-dev] Re: Grok 0.11 released!
On Friday 09 November 2007, Roger Ineichen wrote: > Hi Tres > > > Whoever released those two eggs (the '.dev-r#' ones) need > > to release "real" updated packages, and then grok 0.11.1 > > should be released using them. > > > > DEATH TO FAUX PACKAGES! > > As far as I understand, this does not happen if you > depend on a KGS, right? > > Does the grok release not use the KGS from Stephan? I agree with Roger, Grok should use the KGS and all will be fine. ;-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] bug in ZopePageTemplate.py?
Hi Guys, Can you remember why you added the following line to ZopePageTemplate.py? content_type = 'text/html' It seems to arbitarily lock new page templates (or subclasses of them) into text/html mode. MailTemplates subclass ZopePageTemplate and expect to be text/plain by default... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Hivurt blog
Hi, every day Hivurt is closer to alfa release, we are doing a lot of job to cleanup source code and adding new functionality. To inform people around I has open blog http://hivurt.wordpress.com/. This is place where we will publish news, screenshots, tips, answers about university and everything. You are welcome! -- Mikhail Kashkin, skype:mkashkin, jabber:[EMAIL PROTECTED] Key Solutions (http://keysolutions.ru/) Offshore Zope3 development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Thu Nov 8 13:00:00 2007 UTC to Fri Nov 9 13:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Nov 8 20:52:18 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008616.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Nov 8 20:53:48 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008617.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Nov 8 20:55:18 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008618.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Nov 8 20:56:48 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008619.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Nov 8 20:58:19 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008620.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
AW: [Zope-dev] Re: Grok 0.11 released!
Hi Tres > Whoever released those two eggs (the '.dev-r#' ones) need > to release "real" updated packages, and then grok 0.11.1 > should be released using them. > > DEATH TO FAUX PACKAGES! As far as I understand, this does not happen if you depend on a KGS, right? Does the grok release not use the KGS from Stephan? Regards Roger Ineichen > Tres. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
