Re: [Zope-dev] zope.site.hooks
* 2009-10-07 22:40, Martijn Faassen wrote: > I think it would be interesting to review zope.component.zcml and see how > it depends on security, and see whether we cannot make the dependency > optional too. I fully agree with this, and the main reason why I use a package like repoze.zcml is to get rid of the (unnecessary) dependency on zope.security. The only problem with making the dependency on zope.security optional is related to the "permission" attribute in the zope.component ZCML directives, which is a zope.security.zcml.Permission. All the proxying stuff can be made optional with conditional imports. I think the only solution to make zope.security optional without removing the "permission" attribute is to do something like: try: from zope.security.zcml import Permission except ImportError: from zope.schema import TextLine as Permission Do anybody else has better ideas? Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martin Aspeli wrote: >> Tres Seaver palladion.com> writes: >> >>> There is no way to tell the difference between a WebDAV GET and a >>> "normal" browser GET, period: the specs explicitly, deliberately >>> overload the GET verb. >>> >>> Hence the IANA-assigned "WebDAV source port"[1] (9800) (which *we* >>> requested) in order to disambiguate those requests. >> Heh, nice. That said, though: we know which port Zope is listening to for WebDAV. Even if it's 80 or 81 or whatever, we should be able to detect a DAV request by correlating the port on which the request was received with the address of the server in zope.conf. True, we probably also allow DAV over the "http" port, but if that's a bit broken, I don't see a huge problem telling people to use a dedicated port. Do you see any problems with this? >> Unfortuantely, there's no way to guarantee people will only use this port for >> Zope's WebDAV server. >> >> That said, the two problems (WebDAV requests result in a browserDefault >> lookup, >> and folder contents) are not really an issue in everyday use for GET request. >> They merely cause things to explode on PUT requests to a null resource. We >> *can* >> identify PUT requests, obviously. > > Strictly, PUT is not WebDAV-specific; however, it might be reasonable > to apply the policy you are requesting for any PUT. True. >> So any comments on my proposal to skip the browserDefault lookup and the >> acquisition of resources for PUT/PROPFIND/PROPPATCH requests? > > +.5, I guess. I'd like to make sure that we aren't breaking some other > use first. I'll run the tests? :) 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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Tres Seaver palladion.com> writes: > >> There is no way to tell the difference between a WebDAV GET and a >> "normal" browser GET, period: the specs explicitly, deliberately >> overload the GET verb. >> >> Hence the IANA-assigned "WebDAV source port"[1] (9800) (which *we* >> requested) in order to disambiguate those requests. > > Heh, nice. > > Unfortuantely, there's no way to guarantee people will only use this port for > Zope's WebDAV server. > > That said, the two problems (WebDAV requests result in a browserDefault > lookup, > and folder contents) are not really an issue in everyday use for GET request. > They merely cause things to explode on PUT requests to a null resource. We > *can* > identify PUT requests, obviously. Strictly, PUT is not WebDAV-specific; however, it might be reasonable to apply the policy you are requesting for any PUT. > So any comments on my proposal to skip the browserDefault lookup and the > acquisition of resources for PUT/PROPFIND/PROPPATCH requests? +.5, I guess. I'd like to make sure that we aren't breaking some other use first. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrObj0ACgkQ+gerLs4ltQ7LdwCfY9lYC0JWbWKLhWyzFLVmUDKi UkwAnjlqpIYZvEu+UiAsC6kM3fU+yEXW =K0kT -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security in the KGS
> I think you will need to update your own application specific version > set. The Zope 3 KGS is currently unmaintained. The future of the Zope > 3 project is currently unknown. The last release has been eight months > ago and there is currently no active maintenance going on. My bad, I should've been looking at the ZTK KGS, which has the updated version. Thanks. --Jackie Murphy ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security in the KGS
On Thu, Oct 8, 2009 at 5:15 PM, John Murphy wrote: > We recently were bit by a segfault bug in zope.security > (https://bugs.launchpad.net/zope3/+bug/181833) when migrating an > application from Python 2.4 to 2.6. The newest zope.security (3.7.1, > http://pypi.python.org/pypi/zope.security/3.7.1#id1) has a fix for the > bug. > > We noticed that the KGS 3.4.0b2 uses zope.security 3.4.0 and KGS > 3.5dev uses zope.security 3.6.0, both of which are vulnerable to this > bug. It would be great if the fixed version was incorporated into the > KGS soon, as segfaults during garbage collection are pretty serious -- > not to mention tough to track down :) I think you will need to update your own application specific version set. The Zope 3 KGS is currently unmaintained. The future of the Zope 3 project is currently unknown. The last release has been eight months ago and there is currently no active maintenance going on. Sorry, Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zc.buildout/trunk/src/zc/buildout/buildout.py comparing requirement locations instead of requirement objects
Tarek Ziade wrote: > Log message for revision 104933: > comparing requirement locations instead of requirement objects Did I miss the CHANGES.txt update? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Martin Aspeli wrote: > Martin Aspeli wrote: > >> Right, sorry, I must've been tired when I read this. In my mind, I read >> it as "disallow-picked-versions = false". :) > > No, I'm not crazy after all. The thread is about *removing* > "allow-picked-versions=false" i.e. allowing versions to be picked. I > don't not hate those double negatives, dammit. We're talking about moving it from ztk.cfg to buildout.cfg. ztk.cfg should pin versions and that's it. It shouldn't have any other policy, whether it's disallow-picked-versions or dumppickedversions. People who want to see which versions got picked *in their own projects* (using ztk.cfg or not) can use the dumppickedversions story. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.security in the KGS
We recently were bit by a segfault bug in zope.security (https://bugs.launchpad.net/zope3/+bug/181833) when migrating an application from Python 2.4 to 2.6. The newest zope.security (3.7.1, http://pypi.python.org/pypi/zope.security/3.7.1#id1) has a fix for the bug. We noticed that the KGS 3.4.0b2 uses zope.security 3.4.0 and KGS 3.5dev uses zope.security 3.6.0, both of which are vulnerable to this bug. It would be great if the fixed version was incorporated into the KGS soon, as segfaults during garbage collection are pretty serious -- not to mention tough to track down :) --Jackie Murphy ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Martin Aspeli wrote: > Right, sorry, I must've been tired when I read this. In my mind, I read > it as "disallow-picked-versions = false". :) No, I'm not crazy after all. The thread is about *removing* "allow-picked-versions=false" i.e. allowing versions to be picked. I don't not hate those double negatives, dammit. 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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Hanno Schlichting wrote: > On Thu, Oct 8, 2009 at 2:59 PM, Martijn Faassen > wrote: >> Martin Aspeli wrote: >>> If we do that, I'd also suggest we use the 'buildout.dumppickedversions' >>> extension. >> Does that make sense? After all, if we say allow-picked-version is >> false, there never will *be* any picked versions to dump. Or am I >> misunderstanding something? > > It doesn't make sense. With "allow-picked-version = false" you will > always get an error telling you which package and which version has > been picked but wasn't pinned. Once your build succeeds > buildout.dumppickedversions jumps in and will always present you with > an empty list. Right, sorry, I must've been tired when I read this. In my mind, I read it as "disallow-picked-versions = false". :) > Given that buildout.dumppickedversions is GPL whose use is > questionable in svn.zope.org, Surely, using the extension isn't an issue. It's just referenced by name and installed. That's like saying you can't use gcc (which I assume is GPL licensed) to build C extensions. > I'd just stick with using > allow-picked-version in buildout.cfg. Right. One is not an alternative to another. But it's useful to know what got picked, if you allow things to get picked, and it can be hard to pin everything always. Sometimes, you want to get newer versions precisely so that you can test new things without having to know that a new release is available and update your pins. Anyway, different issue. 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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Testrunner option for running tests in random order?!?
Hi Christian, On Fri, Oct 2, 2009 at 2:00 PM, Christian Theune wrote: > Hi, > > I *thought* the test runner had a feature to run tests in randomized > order, but I can't find it. Is that something that Zope 2 had and that > was never ported to zope.testing? > > I couldn't find in the history either. > > /me is confused. I was about to send the same mail today, but I found out your mail before. I didn't find anything relative to random tests in Zope 2 (but I'm not familiar at all with Zope 2, so I'm pretty sure I could have missed something), and I ended up writing a new feature for zope.testing's testrunner. I made a branch 'shuffle-tests', available on the Mercurial repository at http://bitbucket.org/multani/zope.testing-shuffle/ , which adds two new options: * --shuffle to randomize the order of the tests in a layer (layers are not yet randomized, I didn't look at it yet); * --shuffle-seed XXX, to initialize the RNG with a specific value, which allows to reproduce a specific randomization of tests (inspired by this thread http://lists.idyll.org/pipermail/testing-in-python/2009-April/001812.html ) It's not yet ready-to-commit: it still misses tests (tricky to write) and more documentation. However, feedbacks are welcome! Cheers, Jonathan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Martijn Faassen wrote: > Martin Aspeli wrote: >> Hanno Schlichting wrote: >>> On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen >>> wrote: > [ztk.cfg] contains a line > allow-picked-versions = false I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it. [...] >> If we do that, I'd also suggest we use the 'buildout.dumppickedversions' >> extension. This prints the picked versions with some explanation >> about >> what required them, either to a file or to the console. This is a >> useful sanity check: if you see a package in there that looks spurious >> you may ask whether it should've been pinned somewhere. > > Does that make sense? After all, if we say allow-picked-version is > false, there never will *be* any picked versions to dump. Or am I > misunderstanding something? I think Martin wants to dump picked versions in the case that allow-picked-versions=false is removed from ztk.cfg. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
On Thu, Oct 8, 2009 at 2:59 PM, Martijn Faassen wrote: > Martin Aspeli wrote: >> If we do that, I'd also suggest we use the 'buildout.dumppickedversions' >> extension. > > Does that make sense? After all, if we say allow-picked-version is > false, there never will *be* any picked versions to dump. Or am I > misunderstanding something? It doesn't make sense. With "allow-picked-version = false" you will always get an error telling you which package and which version has been picked but wasn't pinned. Once your build succeeds buildout.dumppickedversions jumps in and will always present you with an empty list. Given that buildout.dumppickedversions is GPL whose use is questionable in svn.zope.org, I'd just stick with using allow-picked-version in buildout.cfg. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Martin Aspeli wrote: > Hanno Schlichting wrote: >> On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen >> wrote: >>> > [ztk.cfg] contains a line >>> >>> > allow-picked-versions = false >>> >>> I agree with Thomas that we should remove this from ztk.cfg, as if we >>> publish this for reuse we don't want to impose this policy on everybody >>> who builds on it. >>> >>> The question though is why this is in there in the first place. >>> Presumably it is to ensure that the *ZTK* locks down all versions. I >>> think we can reasonably ensure this by moving the >>> 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right? >> Yes, +1 for moving it to the buildout.cfg. > > If we do that, I'd also suggest we use the 'buildout.dumppickedversions' > extension. This prints the picked versions with some explanation about > what required them, either to a file or to the console. This is a useful > sanity check: if you see a package in there that looks spurious you may > ask whether it should've been pinned somewhere. Does that make sense? After all, if we say allow-picked-version is false, there never will *be* any picked versions to dump. Or am I misunderstanding something? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Wed Oct 7 12:00:00 2009 UTC to Thu Oct 8 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Oct 7 20:48:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012728.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Oct 7 20:50:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012729.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Wed Oct 7 20:52:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012730.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed Oct 7 20:54:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012731.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Wed Oct 7 20:56:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012732.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Oct 7 20:58:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012733.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Wed Oct 7 21:00:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012734.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Oct 7 21:02:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012735.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Jim Fulton wrote: > On Wed, Oct 7, 2009 at 8:50 PM, Martin Aspeli > wrote: >> Hanno Schlichting wrote: >>> On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen >>> wrote: > [ztk.cfg] contains a line > allow-picked-versions = false I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it. The question though is why this is in there in the first place. Presumably it is to ensure that the *ZTK* locks down all versions. I think we can reasonably ensure this by moving the 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right? >>> Yes, +1 for moving it to the buildout.cfg. >> If we do that, I'd also suggest we use the 'buildout.dumppickedversions' >> extension. This prints the picked versions with some explanation about >> what required them, either to a file or to the console. This is a useful >> sanity check: if you see a package in there that looks spurious you may >> ask whether it should've been pinned somewhere. > > Running buildout in verbose mode (-v) gives you this same information. > Is the idea that this information gets printed even in normal mode? Yeah: - it gets printed always, summarised at the end - it's a lot more concise than the -v output and easier to read - the output is usable as a [versions] block and can be output to a file I use a pattern where I have a devel.cfg that pins some things but allow certain dependencies to float, and then writes the versions it picks to kgs.cfg. For production deployments, there's a production.cfg which (among other things) extends this kgs.cfg. The idea is that once we have a known good configuration in development, we check that file into svn so we have a record, and make sure that absolutely everything is pinned in production. 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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
On Wed, Oct 7, 2009 at 8:50 PM, Martin Aspeli wrote: > Hanno Schlichting wrote: >> On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen >> wrote: >>> > [ztk.cfg] contains a line >>> >>> > allow-picked-versions = false >>> >>> I agree with Thomas that we should remove this from ztk.cfg, as if we >>> publish this for reuse we don't want to impose this policy on everybody >>> who builds on it. >>> >>> The question though is why this is in there in the first place. >>> Presumably it is to ensure that the *ZTK* locks down all versions. I >>> think we can reasonably ensure this by moving the >>> 'allow-picked-versions' to the ZTK's "buildout.cfg" instead, right? >> >> Yes, +1 for moving it to the buildout.cfg. > > If we do that, I'd also suggest we use the 'buildout.dumppickedversions' > extension. This prints the picked versions with some explanation about > what required them, either to a file or to the console. This is a useful > sanity check: if you see a package in there that looks spurious you may > ask whether it should've been pinned somewhere. Running buildout in verbose mode (-v) gives you this same information. Is the idea that this information gets printed even in normal mode? Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Chris Withers wrote: > Martin Aspeli wrote: >> If we do that, I'd also suggest we use the 'buildout.dumppickedversions' >> extension. This prints the picked versions with some explanation about >> what required them, either to a file or to the console. This is a useful >> sanity check: if you see a package in there that looks spurious you may >> ask whether it should've been pinned somewhere. > > This should really be in buildout core. > > Who maintains this extensions and could they be persuaded to merge it > into the main code base? Mustapha Benali. See PyPI. I don't know if it needs to be in the core. Just do [buildout] extensions = buildout.dumppickedversions ... And you're done. 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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Removing zope.testrecorder from the ZTK
On Thu, Oct 8, 2009 at 2:51 AM, Martin Aspeli wrote: > I know a lot of people are using testrecorder with Plone. That doesn't > mean it has to be in the ZTK of course. Never heard of anyone who did. zope.testbrowser is used quite a bit, if that's what you meant. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] allow-picked-versions=false in ztk.cfg?
Martin Aspeli wrote: > If we do that, I'd also suggest we use the 'buildout.dumppickedversions' > extension. This prints the picked versions with some explanation about > what required them, either to a file or to the console. This is a useful > sanity check: if you see a package in there that looks spurious you may > ask whether it should've been pinned somewhere. This should really be in buildout core. Who maintains this extensions and could they be persuaded to merge it into the main code base? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
