[Zope-dev] problem with svn commit on svn.zope.org: "read-only file-system"???
$ svn commit -m '[message omitted]' Sendingsrc/zope/testbrowser/cookies.py Sendingsrc/zope/testbrowser/cookies.txt Transmitting file data ..svn: Commit failed (details follow): svn: Can't create directory '/svn/repos/main/db/transactions/ 92837-1.txn': Read-only file system $ svn info Path: . URL: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/branches/gary- cookie Repository Root: svn+ssh://svn.zope.org/repos/main Repository UUID: 62d5b8a3-27da-0310-9561-8e5933582275 Revision: 92753 Node Kind: directory Schedule: normal Last Changed Author: gary Last Changed Rev: 92653 Last Changed Date: 2008-10-28 06:23:44 -0400 (Tue, 28 Oct 2008) Is this fun unique to me, or something problematic on svn.zope.org? Thanks, Gary ___ 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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Dec 8, 2008, at 9:02 AM, Benji York wrote: > On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick > <[EMAIL PROTECTED]> wrote: >> Log message for revision 93722: >> - Switched to Zope 3.4 KGS. >> >> - New lines are no longer stripped in XML and HTML code contained >> in a >> textarea; requires ClientForm >= 0.2.10 (LP #268139). > > This revision make the buildout fail with > > Error: Couldn't find a distribution for 'ClientForm>=0.2.10'. > > I suspect you had that version of ClientForm in your cache and didn't > realize that it is not available in the KGS index. > > Even if we fixed that, I don't want to require a particular version of > ClientForm in testbrowser. There's no need to impose a newer > version on > people who don't need it. Anyone who does need the bug fix can > specify > the newer version in their project. FWIW, I disagree. The specification that you removed is exactly the sort of thing that I think is appropriate in setup.py. The tests will now fail (I assume, since I believe Christian Z added testbrowser tests for the failure caused by the ClientForm bug) with a lower version of ClientForm, so it is appropriate to set the value in setup.py. Gary ___ 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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Dec 8, 2008, at 10:52 AM, Benji York wrote: > On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster <[EMAIL PROTECTED]> > wrote: >> >> On Dec 8, 2008, at 9:02 AM, Benji York wrote: >> >>> On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick >>> <[EMAIL PROTECTED]> >>> wrote: >>>> >>>> Log message for revision 93722: >>>> - Switched to Zope 3.4 KGS. >>>> >>>> - New lines are no longer stripped in XML and HTML code contained >>>> in a >>>> textarea; requires ClientForm >= 0.2.10 (LP #268139). >>> >>> This revision make the buildout fail with >>> >>> Error: Couldn't find a distribution for 'ClientForm>=0.2.10'. >>> >>> I suspect you had that version of ClientForm in your cache and >>> didn't >>> realize that it is not available in the KGS index. >>> >>> Even if we fixed that, I don't want to require a particular >>> version of >>> ClientForm in testbrowser. There's no need to impose a newer >>> version on >>> people who don't need it. Anyone who does need the bug fix can >>> specify >>> the newer version in their project. >> >> FWIW, I disagree. The specification that you removed is exactly >> the sort of >> thing that I think is appropriate in setup.py. The tests will now >> fail (I >> assume, since I believe Christian Z added testbrowser tests for the >> failure >> caused by the ClientForm bug) with a lower version of ClientForm, >> so it is >> appropriate to set the value in setup.py. > > Nope, the tests will pass in the zope.testbrowser buildout. That's not what I said. :-) > However, if a testbrowser user for some reason run the testbrowser > tests > outside of its buildout, then you're right, they may see a failure if > their versions aren't new enough. At that point I would hope they > would > read the CHANGES.txt and see that a new version is required. > > The trade off is in requiring people to upgrade a dependency in > order to > get a bug fix that they may not care about. > > In the large, this is the problem with specifying versions in > setup.py. > Doing so assumes too much about how people are using all the > dependencies involved. > > Here's a scenario: I fix a bug in some package, it depends on a newer > version of say, zope.publisher. I put that requirement in my > package's > setup.py. A user of my package upgrades to get an unrelated bug fix > and > is forced to use the newer zope.publisher. It so happens that that > the > new version of zope.publisher has a different bug that bites them. > They > now are in a bad spot. > > If the setup.py hadn't specified a version then the programmer could > have constructed a set of versions that didn't exhibit any bugs that > bite them, but they're precluded from doing that. There are always scenarios with problems in which code depends on other packages. I disagree with your argument, but if no-one else agrees with me I'm fine. Gary ___ 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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Dec 8, 2008, at 12:23 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Benji York wrote: >> On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster <[EMAIL PROTECTED]> >> wrote: >>> On Dec 8, 2008, at 9:02 AM, Benji York wrote: >>> >>>> On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick <[EMAIL PROTECTED] >>>> > >>>> wrote: >>>>> Log message for revision 93722: >>>>> - Switched to Zope 3.4 KGS. >>>>> >>>>> - New lines are no longer stripped in XML and HTML code >>>>> contained in a >>>>> textarea; requires ClientForm >= 0.2.10 (LP #268139). >>>> This revision make the buildout fail with >>>> >>>> Error: Couldn't find a distribution for 'ClientForm>=0.2.10'. >>>> >>>> I suspect you had that version of ClientForm in your cache and >>>> didn't >>>> realize that it is not available in the KGS index. >>>> >>>> Even if we fixed that, I don't want to require a particular >>>> version of >>>> ClientForm in testbrowser. There's no need to impose a newer >>>> version on >>>> people who don't need it. Anyone who does need the bug fix can >>>> specify >>>> the newer version in their project. >>> FWIW, I disagree. The specification that you removed is exactly >>> the sort of >>> thing that I think is appropriate in setup.py. The tests will now >>> fail (I >>> assume, since I believe Christian Z added testbrowser tests for >>> the failure >>> caused by the ClientForm bug) with a lower version of ClientForm, >>> so it is >>> appropriate to set the value in setup.py. >> >> Nope, the tests will pass in the zope.testbrowser buildout. > > Having tests which pass only in that buildout is an "attractive > nuisance": I'm seeing test failures in the version of > zope.testbrowser > linked into the Zope2 trunk, for instance. > > If the behavior of zope.testbrowser is broken in the absence of a > sufficiently-recent version of ClientForm, then that behavior should > be > spelled out in setup.py's dependencies: that is what they are for. > >> However, if a testbrowser user for some reason run the testbrowser >> tests >> outside of its buildout, then you're right, they may see a failure if >> their versions aren't new enough. At that point I would hope they >> would >> read the CHANGES.txt and see that a new version is required. >> >> The trade off is in requiring people to upgrade a dependency in >> order to >> get a bug fix that they may not care about. >> >> In the large, this is the problem with specifying versions in >> setup.py. >> Doing so assumes too much about how people are using all the >> dependencies involved. >> >> Here's a scenario: I fix a bug in some package, it depends on a >> newer >> version of say, zope.publisher. I put that requirement in my >> package's >> setup.py. A user of my package upgrades to get an unrelated bug >> fix and >> is forced to use the newer zope.publisher. It so happens that that >> the >> new version of zope.publisher has a different bug that bites them. >> They >> now are in a bad spot. > > A user of your package cannot rely on automatic dependency > resolution in > this case: your package is broken without the new version of its own > dependency, so they can't upgrade to it. > > Stripping all versions from the dependencies in setup.py only works if > users are willing to run their own package indexes, and figure out > edge > cases such as the ones you describe by themselves: at that point, > forking the egg to drop the manually-resolved extra dependency is a > minor nuisance. Thank you for taking the time to think through and clearly describe the position I share, Tres. Gary ___ 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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.
On Dec 9, 2008, at 8:43 AM, Benji York wrote: > On Mon, Dec 8, 2008 at 12:23 PM, Tres Seaver <[EMAIL PROTECTED]> > wrote: > >> Stripping all versions from the dependencies in setup.py only works >> if >> users are willing to run their own package indexes, and figure out >> edge >> cases such as the ones you describe by themselves: > > The above claim appears false. Every project (both the open and > closed) > I work on has virtually no versions in setup.py and we don't use a > private package index. We use a version section in the buildout. The "virtually" is the catch here. They do have some. They are typically introduced when an older version of a dependency *does not work with the software*. To me, "does not work" == "breaks tests". Because our community, and others, try for backwards compatibility, this kind of assertion happens relatively rarely. These setup.py assertions are always, or almost always, not "pinning" but saying "I work with X or better." I'm advocating these sorts of "X or better" assertions. Christian's zope.testbrowser change fits these characteristics. Do you, or Stephan, or anyone else with your opinions, have some other additional line that must be crossed, or do you assert that setup.py should never have any version numbers? For instance, if you have a project that requires a newer API in, say, zope.component, do you assert that it is inappropriate to specify a zope.component of "X or better" in your setup.py for that project? Gary ___ 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] [Checkins] SVN: zc.dict/branches/tlotze-blist/src/zc/dict/ordered.txt added a test to ensure the order is stored in a BList
Hi Thomas. Very cool that you are working on zc.dict + zc.blist. The updateOrder API is a sucky API for blists, as I'm sure you've realized. :-) FWIW, I seem to recall that Plone has a reasonable-to-nice API for changing order in containers, and the API would be able to take much better advantage of using blists for the ordering. I was intending to study that when I designed the new API (even if the Plone API were perfect, I would be wary of copying it because of GPL vs. ZPL, but maybe you could get them to relicense if you wanted it). You'd probably still want to keep updateOrder around, I guess, since that's the Zope 3 interface, but I would have documentation discouraging it. Gary ___ 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] [Checkins] SVN: zc.dict/branches/tlotze-blist/src/zc/dict/ordered.txt added a test to ensure the order is stored in a BList
On Dec 23, 2008, at 2:11 PM, Thomas Lotze wrote: > Thomas Lotze schrieb: > >> Yes, and I think that we're talking about two steps here anyway. I'd >> like to finish and release a version that uses BLists ASAP; > > Well, I think the switch to BLists is finished, so I'd be ready to > merge it to the trunk after someone reviewed the changes. In > particular, I'm not sure that wiring up and testing the database > generation follows best practices. OK. I'll give it a whirl sometime over the next couple of weeks, if that's soon enough for you. FWIW, I'd be strongly tempted to release *without* the generation code, and leave it up to users to switch as they desire. 1) That's particularly pertinent for library bits like this because a tree walker would have to walk over *all* attributes and __getitem__s in order to find instances of things like a blist, which will generally be hidden deep in application objects; or would have to use an iteration protocol like the one that FileStorage provides. 2) Old instances (with lists, not blists) will still work fine with the new code, and in fact should continue to work even with new apis as long as the ordered dict apis use the list apis (like slices) to manipulate the order. 3) How many people are really using the blist right now anyway in production? Generation code is hard to test in the abstract. ___ 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] Some tools from the Launchpad project
Hi all. As announced elsewhere (and described in https://dev.launchpad.net/OpenSourcing) , Canonical's Launchpad project is working towards open-sourcing the majority of the code base by this summer. Prior and subsequent to the "grand open-sourcing" date, the Launchpad developers are encouraged to abstract stand-alone code for distributions. Since Launchpad uses several Zope libraries, some of the stand-alone packages may be of special interest to the Zope community. Unsurprisingly (at least if you know Launchpad), the packages use bzr for revision control, and Launchpad for codehosting, bug tracking, and so on. Currently we are standardizing on zc.buildout-based releases for these packages. We have two at the moment: http://pypi.python.org/pypi/lazr.delegates Provides an interesting Python delegation pattern. Uses zope.interface. http://pypi.python.org/pypi/lazr.config Helps build a configuration system (of whatever, but used here for process configuration). I'm not the author, just a messenger and liaison (and the guy who made the distros, in this case). (I did add some cookie conveniences to testbrowser recenty though--check out zope.testbrowser 1.6a1 if you want a look. :-) I, or other folks, will hopefully get a chance to send out other announcements of this sort in the future! Gary ___ 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] Some tools from the Launchpad project
On Jan 13, 2009, at 4:15 PM, Dan Korostelev wrote: > 2009/1/14 Dan Korostelev : >> 2009/1/13 Gary Poster : >>> >>> http://pypi.python.org/pypi/lazr.delegates >>> >>>Provides an interesting Python delegation pattern. Uses >>> zope.interface. >> >> I took a quick view at that lazr.delegates package. The code there >> is so small, so I think it can be merged in zope.interface itself, >> because >> it can be quite useful together with zope.interface's adapter >> pattern. >> >> What are you people think about including delegates code into >> zope.interface? > > Ah, its GPL. I should have checked out the license before talking > about merging. :) LGPL, actually! An important distinction. If there were enough interest, I'd certainly be happy to propose it at Canonical and see if it could happen. I think there would be several advocates here. Gary ___ 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] Request input on bug about HTTP response.setStatus
Hi all. There's some disagreement about how to resolve the bug below, even though there's agreement that we want it resolved. Your input would be appreciated so we can find a consensus and move forward with a solution. https://bugs.edge.launchpad.net/zope3/+bug/322486 Gary ___ 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] Merge zc.copy with zope.copypastemove and zope.location.
As the author, +1 and thank you! Gary On Feb 8, 2009, at 11:18 AM, Dan Korostelev wrote: > Okay. I prepared the "zope.copy" package in the SVN for you to check > out what I mean. :) > > 2009/2/8 Dan Korostelev : >> After looking at the whole copy thing for some more time, I thought >> that it even makes sense to extract the object cloning functionality >> to some "zope.copy" (or even "zope.persistentcopy") package that will >> contain clone and copy functions as well as ICopyHook mechanism, but >> won't contain IObjectCopier implementation, because the "clone" and >> "copy" functions from zc.copy are useful without any container >> context. Then zope.copypastemove and zope.location could just depend >> on the zope.copy, so we won't introduce many dependencies for >> zope.location and make people able to easily copy persistent objects >> w/o installing on zope.copypastemove or even zope.location. >> >> 2009/2/8 Dan Korostelev : >>> The README.txt of zc.copy says that the components, provided by this >>> package is apropriate for inclusion in Zope itself. >>> >>> The package provides a more pluggable mechanism for copying generic >>> persistent objects (not only ILocation's) as well as a way to >>> register >>> post-copy hooks to be executed, which is very useful, for example >>> when >>> dealing with persistent objects that have non-ZODB bits (like >>> filesystem based files related and so on). However, the package is >>> really small and mostly contains modified copies of >>> zope.copypastemove's ObjectCopier and zope.location's locationCopy. >>> >>> So, I propose to merge the zc.copy package's changes with original >>> zope.copypastemove/zope.location and deprecate it. If noone objects, >>> I'll do that myself. >>> >>> -- >>> WBR, Dan Korostelev >>> >> >> >> >> -- >> WBR, Dan Korostelev >> > > > > -- > WBR, Dan Korostelev > ___ > 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 )
Re: [Zope-dev] Merge zc.copy with zope.copypastemove and zope.location.
On Feb 8, 2009, at 5:18 PM, Dan Korostelev wrote: > 2009/2/9 Gary Poster : >> As the author, +1 and thank you! > > Glad to hear. I'll release the result of the merge soon. > > BTW, I'd also like to make a final release of zc.copy, replacing its > code with dependencies/imports from newer zope.copy and > zope.copypastemove. You mean 1.1. OK. If I were doing it, I would make 1.1b -> 1.1, and then make a 1.2 that was as you described. If you don't agree or feel like it that's fine. > Can you please add me to package owners on PyPI > (my name there is "nadako"). Done. > Also, should I use deprecated deferred > imports or plain imports for that? I'm generally not a fan of the deprecated imports. I'd say just put it in the docs. Again, if you disagree, I don't feel too strongly about it. Gary ___ 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] opensp...@pycon 2009 about Zope/Repoze/Grok/Deliverence etc.
On Feb 9, 2009, at 12:03 PM, Lennart Regebro wrote: > Lots of things have happened in the Zope universe the last couple of > years, and are still happening, some of which are turning Zope inside > out, from a monolithic ghetto to a componentized agile speed monster. > People outside the Zope world doesn't know about it, and although the > Zope community mostly seems to be on the same page, I think it would > be nice if we get as many as possible together to discuss the status > and where things are going. And, if we don't have anything to discuss, > we can drop off to some bar and toast at how great Zope is. :-) > > So, I propose to have an Open Space session at PyCon, Chicago, March > 27-29 . As this is a part of the "unconference" bit of PyCon, you > don't have to sign up, but you can say if you are coming here anyway, > just so we get a feeling for the interest. And although we can't > decide when to do this yet, if you are only able to go to PyCon > certain days, say so here, so we'll know when we can get the most > participants. I'm supposed to be at PyCon, but I haven't seen the confirmation yet. If I'm there, sounds good. Gary ___ 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.testing tests failing on trunk (using Python 2.4.6 and 2.5.4)
zope.testing trunk has five tests failing in Python 2.4.6 and four failing in Python 2.5.4 (on self-compiled versions on Mac OS X). Anyone know what the story is here? Gary ___ 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] zope.testing tests failing on trunk (using Python 2.4.6 and 2.5.4)
On Feb 16, 2009, at 3:11 PM, Marius Gedminas wrote: > On Mon, Feb 16, 2009 at 10:17:06AM -0500, Gary Poster wrote: >> zope.testing trunk has five tests failing in Python 2.4.6 and four >> failing in Python 2.5.4 (on self-compiled versions on Mac OS X). >> >> Anyone know what the story is here? > > No clue, especially since you haven't shown us what the failures are > > (Hint, hint.) :-) They were rather long. I tracked the majority of them down to Theuni, who graciously and quickly fixed them up. (r96602) He said there were some other failures when he started, in Py 2.4 and Py 2.5. I verified this. I corrected the errors in Py 2.5 and did a bit of other cleanup (r96603). One error remains in Py 2.4. I'll include the traceback below. Some paths are not included in Py2.4 for some reason. The cause was not immediately obvious, and I have day-off-and-I-have-a-cold laziness, so I didn't look further. As an aside, in Py 2.6, you get at least two deprecation warnings, and the tests appear to hang. Again, lazy. Didn't bother. Gary File "/Users/gary/dev/zope.testing/src/zope/testing/testrunner/ testrunner-coverage.txt", line 18, in testrunner-coverage.txt Failed example: testrunner.run(defaults) Expected: Running samplelayers.Layer1 tests: Set up samplelayers.Layer1 in N.NNN seconds. Ran 9 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer11 tests: Set up samplelayers.Layer11 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer111 tests: Set up samplelayers.Layerx in N.NNN seconds. Set up samplelayers.Layer111 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer112 tests: Tear down samplelayers.Layer111 in N.NNN seconds. Set up samplelayers.Layer112 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer12 tests: Tear down samplelayers.Layer112 in N.NNN seconds. Tear down samplelayers.Layerx in N.NNN seconds. Tear down samplelayers.Layer11 in N.NNN seconds. Set up samplelayers.Layer12 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer121 tests: Set up samplelayers.Layer121 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer122 tests: Tear down samplelayers.Layer121 in N.NNN seconds. Set up samplelayers.Layer122 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running zope.testing.testrunner.layer.UnitTests tests: Tear down samplelayers.Layer122 in N.NNN seconds. Tear down samplelayers.Layer12 in N.NNN seconds. Tear down samplelayers.Layer1 in N.NNN seconds. Set up zope.testing.testrunner.layer.UnitTests in N.NNN seconds. Ran 192 tests with 0 failures and 0 errors in N.NNN seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in N.NNN seconds. lines cov% module (path) testrunner-ex/sample1/__init__.py) testrunner-ex/sample1/sample11/__init__.py) testrunner-ex/sample1/sample11/sampletests.py) testrunner-ex/sample1/sample13/__init__.py) testrunner-ex/sample1/sample13/sampletests.py) testrunner-ex/sample1/sampletests/__init__.py) testrunner-ex/sample1/sampletests/test1.py) testrunner-ex/sample1/sampletests/test11.py) testrunner-ex/sample1/sampletests/test111.py) testrunner-ex/sample1/sampletests/test112.py) testrunner-ex/sample1/sampletests/test12.py) testrunner-ex/sample1/sampletests/test121.py) testrunner-ex/sample1/sampletests/test122.py) testrunner-ex/sample1/sampletests/test_one.py) testrunner-ex/sample1/sampletestsf.py) testrunner-ex/sample2/__init__.py) testrunner-ex/sample2/sample21/__init__.py) testrunner-ex/sample2/sample21/sampletests.py) testrunner-ex/sample2/sampletests/__init__.py) testrunner-ex/sample2/sampletests/test_1.py) testrunner-ex/sample2/sampletests/testone.py) testrunner-ex/sample3/__init__.py) testrunner-ex/sample3/sampletests.py) testrunner-ex/samplelayers.py) testrunner-ex/sampletests/__init__.py) testrunner-ex/sampletests/test1.py) testrunner-ex/sampletests/test11.py) testrunner-ex/sampletests/test111.py) testrunner-ex/sampletests/test112.py) testrunner-ex/sampletests/test12.py) testrunner-ex/sampletests/test121.py) testrunner-ex/sampletests/test122.py) testrunner-ex/sampletests/test_one.py) testrunner-ex/sampletestsf.py) Total: 405 tests, 0 failures, 0 errors in N.NNN seconds.
Re: [Zope-dev] Single Sign On
Hi Shane. Launchpad uses OpenID. We don't have that slated for abstraction and open-sourcing immediately. However, most of the Launchpad code (including this bit) is to be open-sourced by this summer, abstracted or not. Therefore, we should at least be able to give you some idea of what we have done before then. I've forwarded your email to the primary implementer/designer of our OpenID integration. Hopefully he can directly participate, or at least give me some answers to forward to you. Generally, we're using python-openid for the Zope code, and an Apache plugin as a front-end for hooking up other bits. Gary On Feb 17, 2009, at 7:06 PM, Shane Hathaway wrote: > I'm working with a customer on a single sign on (SSO) system for Zope. > We haven't yet chosen which SSO system we want to use. I would like > to > hear from anyone who has set up SSO with Zope. > > We have some definite requirements: > > * We can't accept arbitrary identities like OpenID normally does. We > need to set up our own identity provider (IDP) and force our servers > to > accept only identities provided by our own IDP. > > * The SSO process should be very similar to an ordinary cookie-based > login process. I don't want the user to have to enter their > username on > one form and their password on another, but that's the standard OpenID > process. > > * This will be implemented in Zope 3. > > We are considering OpenID, Shibboleth, CAS, and any other mature > system > that others might suggest. Shibboleth seems like the most obvious > fit, > but it's nowhere near as popular as OpenID. I haven't yet looked at > CAS > in detail. > > Alternatively, I have wondered if we actually need full-blown SSO; > perhaps a carefully constructed domain-wide cookie would do the trick. > Any experiences with that? > > Thanks to anyone who participates. > > Shane > ___ > 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 )
Re: [Zope-dev] Single Sign On
On Feb 17, 2009, at 7:55 PM, Shane Hathaway wrote: > Gary Poster wrote: >> Launchpad uses OpenID. We don't have that slated for abstraction >> and open-sourcing immediately. However, most of the Launchpad code >> (including this bit) is to be open-sourced by this summer, >> abstracted or not. Therefore, we should at least be able to give >> you some idea of what we have done before then. >> I've forwarded your email to the primary implementer/designer of >> our OpenID integration. Hopefully he can directly participate, or >> at least give me some answers to forward to you. > > Cool, thanks. > >> Generally, we're using python-openid for the Zope code, and an >> Apache plugin as a front-end for hooking up other bits. > > In that case, what do you pass to Consumer.begin()? It expects a > user URL and no password, yet launchpad.net accepts a user name and > password. > > Shane Hi Shane. Francis Lacoste gave this answer: We use the OpenID 2.0 identifier select URL. This is a special OpenID url that basically means: identity using whatever ID you have on that server. The OpenID response will contain the actual OpenID identifier of the user at the end of the request. So sites that we integrate in our SSO simply sends you to Launchpad for authentication and then uses the returned identifier to link with their local account representation. We also use sreg (Simple Registration) to transfer information about the account to the integrated sites, so that they can update their local account representation with the central data. Gary ___ 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] Single Sign On
On Feb 19, 2009, at 2:07 AM, Marius Gedminas wrote: > > I have the impression that you're talking past each other. > > There are two ways of using OpenID: > > * you can be an OpenID provider, i.e. accept logins with username & >password and respond to authentication requests from other websites >confirming that the user does own this particular OpenID. > > * you can be an OpenID consumer, i.e. accept OpenID URLs from users >and ask the corresponding OpenID provider to validate them. > > It's my impression that launchpad.net is an OpenID provider only, > while > Shane is trying to figure out how to use the OpenID consumer API in > AuthKit. > > I could be mistaken about any of the particular points here. I'm glad that Shane replied that what Francis said helped him. FWIW, IRT Launchpad being an OpenID consumer, that's supposed to be a possibility very soon. Gary ___ 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] Review of zc.dict tlotze-blist branch
[Thomas asked me to review his zc.dict branch a while ago.] Hi Thomas. Thank you for this work. It looks great. I do have several comments below (from an abbreviated diff against the current trunk). > Index: buildout.cfg > === > --- buildout.cfg (.../trunk) (revision 97211) > +++ buildout.cfg (.../branches/tlotze-blist) (revision 97211) > @@ -2,11 +2,10 @@ > develop = . > parts = test py > > -find-links = http://download.zope.org/distribution/ > - > [test] > recipe = zc.recipe.testrunner > -eggs = zc.dict > +eggs = zc.dict [generations] > +defaults = ["-v", "-c"] I don't think the generations code should be required, and (since you used extras_require) neither do you. Therefore I'd prefer it if the main tests also didn't depend on that code. The way I've done this with other packages (e.g. http://svn.zope.org/zc.async/trunk/buildout.cfg?view=auto) is to have multiple test sections (with different names). The downside is that then, to run all possible tests, you have to run more than one command. The upside is that arguably the most important configuration--the base one--is truly tested. > > [py] > recipe = zc.recipe.egg > Index: CHANGES.txt > === > --- CHANGES.txt (.../trunk) (revision 97211) > +++ CHANGES.txt (.../branches/tlotze-blist) (revision 97211) > @@ -1,3 +1,8 @@ > +1.3 (unreleased) > + > + > +* changed the implementation of OrderedDict to store the order in buckets I suggest adding "via zc.blist" or something like that. ... > Index: src/zc/dict/configure.zcml > === > --- src/zc/dict/configure.zcml (.../trunk) (revision 0) > +++ src/zc/dict/configure.zcml (.../branches/tlotze-blist) (revision 97211) > @@ -0,0 +1,5 @@ > +http://namespaces.zope.org/zope";> > + > + > + > + configure.zcml has a semantic of "always include." Because the generations code may not work for many people (as we've discussed before, and see comment in evolve test below), I'd prefer that the generations code have a semantic of "optionally include." Therefore, I suggest you rename this to "generations.zcml" or something like that. ... > Index: src/zc/dict/dict.py > === > --- src/zc/dict/dict.py (.../trunk) (revision 97211) > +++ src/zc/dict/dict.py (.../branches/tlotze-blist) (revision 97211) ... > def __setitem__(self, key, value): > -delta = 1 > -if key in self._data: > -delta = 0 > -self._data[key] = value > -if delta: > +if key not in self._data: > self._order.append(key) > -self._len.change(delta) > +self._len.change(1) > +self._data[key] = value Nice improvement in readability. > > def updateOrder(self, order): ... Also as mentioned before on the Zope list, until this API is deprecated in favor of one that encourages more granular changes, the change to blist only really helps the story for adding new items to an ordered dict. The Plone IExplicitOrdering interface looks reasonable, and could really take advantage of the blist characteristics. http://dev.plone.org/plone/browser/plone.folder/trunk/plone/folder/interfaces.py > Index: src/zc/dict/generations/evolve1.txt > === > --- src/zc/dict/generations/evolve1.txt (.../trunk) (revision 0) > +++ src/zc/dict/generations/evolve1.txt (.../branches/tlotze-blist) ... As we discussed earlier, findObjectsMatching will miss OrderedDicts that are used as internal data structures. I regard that as a primary use case for this package, so IMO that's important to note in the doc and in the Python file. Otherwise, looks great to me. Thank you! Gary ___ 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] the Zope Framework project
Thank you for the huge effort you expended on this, Martijn. You are right, with Jim taking a rest from his much-appreciated past years as leader, no one is in a position to guide the "Zope" name. We do have community leaders, such as yourself, but they are guiding other names at the moment. By focusing on reinvigorating the name "Zope," I think we have an opportunity to move forward. This can be done loosely but with an opportunity for people such as yourself to take leadership. Zope Foundation members should be encouraged to propose "Zope"-named umbrella projects. Acceptance should be simple and loose--on the order of, you send an email to the ZF list to request use of a new "Zope" name, and the default answer to ZF members is "yes, unless someone challenges it to a vote within four days, with simple majority rule in the ZF". That's a straw man, but hopefully conveys the idea. For instance and hypothetically, if you tomorrow wanted to start a new project called "Zope Rocks" that was to be some substrate of Grok, you should be encouraged. Moreover, if you are willing to step up and declare that you are starting something called the "Zope Framework" that manages a known good set of code, and you hope other projects and people join in and help, that makes sense to me. With what I've seen on the Grok list, you can do a great job as a project leader, generally being positive, open, and motivating. And importantly, it's just a use of the name: "Zope". Other ZF developers might come along and say "that Martijn character knows nothing--come join be on Zope Super Framework Libraries!" I don't think they will, but they could, and would likely be given the same opportunity, given the "simple and loose" approach I described. That said, I suspect the vast majority of people will be appreciative of your efforts, and I suspect that you'll be able to marshal cooperation among many of the consumers of the current crop of Zope libraries. People that want a leadership position will seek you out and help. Hopefully you can get along. If not, watch out for the competing "Zope Super Framework Libraries," coming soon. So that's what I would prefer, instead of the elected steering group. You want it, you do it. And Martijn, I hope you do. And if not, sure, I'll vote for the "steering group," hopefully guided by the Plone experience Martin is recounting, just so we have *something*. Gary ___ 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] the Zope Framework project
On Mar 3, 2009, at 7:35 AM, Martijn Pieters wrote: ... > And so far I haven't heard any better ideas than > what Martijn is proposing (no, leaving the status quo, deny there is a > problem and steer by majority is not a counter proposal in my view). > It may be that the idea needs some tweaking, but that's just details. > > Would it be possible to focus this discussion around clearer lines? > Create counter proposals if you have to ... I'm surprised my proposal didn't generate any replies, and can only assume that it is because it created the silence of everyone quietly saying "Whaaa?" :-) My mild counter proposal was this. - The ZF formally institutes an easy way for people to start "Zope" projects - Hopefully, Martijn F. starts something like the project he described - Hopefully, people follow it. In other words, I suppose, Just Do It. I don't think Martijn, nor anyone else who has been part of the community long enough to be on the ZF, needs the entire community to bless his idea to try to move forward--they need just an absence of a veto for the use of the chosen name, as I proposed more concretely in the original email. I think that incorporates some of the more laissez-faire advocates are arguing for: someone else can also start their own counter project, if desired. Maybe they won't, but they can. And this freedom could allow us to escape the need to feel that everyone has to agree about this. Beyond that, I didn't say my other smaller thought, which was that I think the KGS should ideally be looser and more flexible than what Martijn described. If you have a project that wants in on the KGS, great, you can add it. Institute a "nightly" KGS for an upcoming release (and maybe the most recent release). It stays around forever at a specific URL. Include only the projects whose tests pass in the nightly KGS. Have a list elsewhere of the ones for which the tests fail. If the tests don't pass for some period of time, apparently the maintainers and users don't exist or don't care, and they get taken off the list to be tested. The "Zope Framework" team leader then decides some time to make a release, so people might shuffle around versions more than usual, but it's just another KGS. Gary ___ 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] the Zope Framework project
On Mar 3, 2009, at 12:31 PM, Martijn Faassen wrote: > Hey Gary, > > [panarchist approach where we have people starting groups that could > compete for attention] [Had to look up panarchist, but yes, essentially.] > I agree that it should be relatively easy to start "Zope" projects > under > the Zope umbrella. > > I agree that such projects could compete for attention and may the > best > one win. > > I think this is what's more or less already happening anyway, and I > think it's great and it makes me appreciative of open source and > Zope's > component oriented culture that makes it possible. > > We can't just fork everything and branch off into our direction > everywhere however; these projects will share a common codebase. I am very much in favor of someone having this perspective, and acting on it. ;-) > This common codebase needs to be managed and have a direction, > taking as > inputs the needs of the projects using them. We don't have an umbrella project (e.g., grok, repoze) with this goal. I think your statements and mine mesh well enough. If you don't agree, that's fine. Practically, it means I support what you are trying to do (and in fact I would tend towards your camp in my proposed panarchy), if from a slightly different perspective. > > Gary Poster wrote: >> Moreover, if you are willing to step up and declare that you are >> starting something called the "Zope Framework" that manages a known >> good set of code, and you hope other projects and people join in and >> help, that makes sense to me. > > The open source mantra: "those who take responsibility get > responsibility" Yup. > I agree very much with that. > > It might be we are able to establish a "framework team" without > elections by just picking out the bunch of people who are interested > in > this. Of course if we have a significant fraction of our community who > disagrees with the authority to make decisions for larger changes in > these components, we still have a problem. Two diverging branches of > the > same package doesn't seem to be a maintainable situation; at some > point > someone is going to make a release with a single version number. > > That's why I don't think I or anyone else can just "do it" without > reaching a bit of wider consensus first. I think we have a transition > problem to get from where we are now, where everybody and nobody is > recognized, to a generally recognized group with some authority to > make > decisions where needed and provide guidance that should be taken into > account. Sure. I'm glad you sent your proposal email first. Now that you have, I hope you pursue your vision without needing 100% buy-in from the community. I'm optimistic that you will. :-) Gary >> With what I've seen on the Grok list, >> you can do a great job as a project leader, generally being positive, >> open, and motivating. > > Thanks! I have my flaws, but I try to be aware of them. :) Yup, same here. Gary ___ 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] the Zope Framework project
On Mar 3, 2009, at 10:57 AM, Stephan Richter wrote: > On Tuesday 03 March 2009, Gary Poster wrote: >> My mild counter proposal was this. >> >> - The ZF formally institutes an easy way for people to start "Zope" >> projects >> >> - Hopefully, Martijn F. starts something like the project he >> described >> >> - Hopefully, people follow it. >> >> In other words, I suppose, Just Do It. > > Actually Martijn tried to be better than that. :-) Instead of just > forming a > steering group (which I would interpret as a Zope project) and > announcing it > to the community, he asked for feedback first. :-) :-) Yes, that is better. > I probably agree he should have just done it by gathering the > various release > managers. BTW, in one of my original responses, I proposed to > Martijn that > the steering group should be mostly the release managers plus one or > two > strong developers so that the group reaches an odd number. Now that he's proposed it, hopefully he does it, without 100% buy-in, as I just wrote to Martijn. >> Beyond that, I didn't say my other smaller thought, which was that I >> think the KGS should ideally be looser and more flexible than what >> Martijn described. If you have a project that wants in on the KGS, >> great, you can add it. > > That is the case right now and I think a steering group would be > pretty open > to additions. > > However, I think Martijn made a much more important point. What he > wants, if I > understood him correctly, is more of an organization around a > hierarchy of > KGSs. OK. > The reason for this is that Zope/Plone, grok, and Zope 3 AS all > share a > common core and maybe a coreplus set. Then each sub-project > maintains a KGS > on top of that with their specific extensions. > > (1) This will make interoperability much easier, since I could > potentially use > grok X.Y in Zope 2.Z without worrying about version conflicts. > > (2) If the steering group contains all of the release managers, then > releases > can be synced effectively. > >> Institute a "nightly" KGS for an upcoming >> release (and maybe the most recent release). > > We do have this system today. > > http://zope3.afpy.org/buildbot/waterfall Wow, great. Too bad about the failures. How are you announcing the failures ATM? >> It stays around forever >> at a specific URL. Include only the projects whose tests pass in the >> nightly KGS. Have a list elsewhere of the ones for which the tests >> fail. If the tests don't pass for some period of time, apparently >> the >> maintainers and users don't exist or don't care, and they get taken >> off the list to be tested. > > That statement is a massive over-simplification of what's going > on. ;-) Heh, well, that's not exactly a surprise. :-) > There > are several problems: > > (1) Tests that pass in isolation might not pass in a complete run. > This might > be due to this or another packages incomplete teardown. (Several > people spent > weeks getting this right for the 3.4 KGS.) > > (2) A new release of one package might break 5 others. Who is > responsible for > updating the 5 breaking packages. The author that just released the > new > package or the ones from the 5 others? What if those other packages > do not > have clear, single maintainers (e.g. zope.*)? > > I am not making up these cases. They are real and they exist today. I know you are correct. I've experienced very similar things myself. > The idea > that one package has 1 or more concrete and devoted authors is > simply not > real in the Zope world of 200+ packages. Sure. There certainly are stakeholders who are willing to invest on this, particularly on core packages (where "core" differs for the stakeholders). >> The "Zope Framework" team leader then >> decides some time to make a release, so people might shuffle around >> versions more than usual, but it's just another KGS. > > Yep, this is basically what happens today. For example, at Keas we use > different versions (even trunk) of at least 20 packages. The point > is that > people have a stable point to start with. I think that would not > change. Great. (And thank you, this is much farther along than the last time I looked.) FWIW, the only polish I'd love to see is static pages for past dev releases (or did I miss them?) Thanks, Gary ___ 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] Review of zc.dict tlotze-blist branch
On Mar 4, 2009, at 2:20 AM, Thomas Lotze wrote: > Gary Poster schrieb: > >>> Index: src/zc/dict/configure.zcml >>> === >>> --- src/zc/dict/configure.zcml (.../trunk) (revision 0) >>> +++ src/zc/dict/configure.zcml (.../branches/tlotze-blist) >> (revision 97211) >>> @@ -0,0 +1,5 @@ >>> +http://namespaces.zope.org/zope";> >>> + >>> + >>> + >>> + >> >> configure.zcml has a semantic of "always include." Because the >> generations code may not work for many people (as we've discussed >> before, and see comment in evolve test below), I'd prefer that the >> generations code have a semantic of "optionally include." Therefore, >> I suggest you rename this to "generations.zcml" or something like >> that. > > Wouldn't it be simpler to just remove this file as it does nothing but > include the configure.zcml of a sub-package? Using the generations > configuration would then read package="zc.dict.generations" /> > instead of which > wouldn't be for the worse either IMO. +1, good idea >> Also as mentioned before on the Zope list, until this API is >> deprecated in favor of one that encourages more granular changes, the >> change to blist only really helps the story for adding new items to >> an >> ordered dict. >> >> The Plone IExplicitOrdering interface looks reasonable, and could >> really take advantage of the blist characteristics. > > I do have that on my to-do list. Do you think we should add some > comment > about this to the code? I think the current performance characteristics are important to note somewhere, at least. Even CHANGES would be sufficient. Thanks, Gary ___ 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] Standard request/response API
On Mar 1, 2009, at 1:00 PM, Jim Fulton wrote: > > There's been some discussion recently about separating the interfaces > in zope.publisher from the implementations to facilitate other > implementations. > > I think it would be great to standardize request and response APIs. > I'd love to see this extend beyond the Zope community. I believe > that there have been some moves to try to do this at the WSGI level, > although I haven't kept up with the discussion. > > Speaking for myself, I'd be happy to change my code to comform to a > python-standard request API assuming that it had enough in it to adapt > it to existing APIs. > > This might be an excellent project for PyCon. Hey. I have some other projects to work on there as well, but I'll be at PyCon, and am interested in helping on this (specifically the WebOb idea already discussed). Gary ___ 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 3 app server dying? (was Re: the Zope Framework project)
On Mar 5, 2009, at 6:38 AM, Hermann Himmelbauer wrote: > > And I am personally interested if the Zope 3 app server is something > that's > dying in favour for other projects (Plone/Grok) or is actively used. Not clear on what you mean by the "app server". If you mean zope.publisher, no, I don't think it is dying. The proposals to learn from repoze's approach, and hopefully integrate with WebOb, mean that this is alive and kicking. Also, to varying degrees, some medium-to-big companies are sitting on top of it, and these companies IME tend to have big code bases that tend to change decisions like this slowly. Also, I'm pretty sure Grok also sits on top of much of the publisher machinery. On the other hand, I personally have the impression that the basic Zope 3 ZMI is pretty much dying or dead. Grok and Plone are the only ones innovating in that space (in extremely different ways, of course), as far as I can tell. Gary ___ 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] setup.py "extra" dependencies
On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote: > Hi there, > > I know opinions are divergent about 'extra' dependencies in setup.py. > These ar dependencies that effectively make a single project with a > single dependency structure into a number of "virtual" packages that > each can have a separate list of dependencies. Such a virtual package > that we're currently getting rid of is zope.component[zcml]. ... > Opinions? I disagree with the blanket statement. I do lean towards not having the extras for the test package only. I'm fine with the policy "If you want zope.testing for your tests, then keep it as a dependency for the package". But I like to have the option of extras for testing additional setups. zc.async uses extras so that the main tests show the functionality as a Python library; another level adds more Zope dependencies, with associated tests; and the last level adds the most. I could have divided these up into multiple teensy-weensy packages but I didn't really want to. It seemed like overkill. I've also done this in other circumstances in which code could use zope.proxy/zope.security, but I really didn't want to add the hard dependency. The tests to show that proxies were handled correctly were only part of the "extras". Dividing this package also would have made no sense--it was already just a few small classes. For a package as central as zope.component, I think the pattern Tres is pursuing--dividing everything up--makes sense. For most other packages, I personally feel that there are circumstances in which extras are a useful tool. I do wonder if there's a ``setup.py test`` spelling for testing these extras though. If there were not, I'd find that a good argument against the "extras" pattern, at least for core Zope packages. Gary ___ 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] setup.py "extra" dependencies
On Mar 6, 2009, at 9:50 AM, Martijn Faassen wrote: > Hi there, > > Thanks Gary for sketching our the zc.async usecase. Note that zc.async > isn't in the Zope Framework at this point in time so it wouldn't be > directly affected by this policy, but it's still a useful usecase of > course. Right, that was the intent. ... > * we are going to work at getting rid of the zope.app.testing extra by > distributing its facilities into individual zope.* packages. Hopefully > we can get a clear consensus on this one from the people who object to > the general policy. +1 > * if you think a new "extra" dependency is needed in a Zope Framework > package, and you're not just moving stuff between packages but > actually > developing new code, bring it up on zope-dev so we can at least > consider > alternatives. Perhaps a better home can be found for this code. Fair enough. > * on a case-by-case basis we can consider removing extra dependencies > for particular Zope Framework packages, just like what we're doing > right > now for zope.component. We'll discuss that whenever needed. I'll of > course be biased in favor of such removal, but I can be convinced > otherwise. Fair enough. Thanks Gary ___ 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] setup.py "extra" dependencies
On Mar 6, 2009, at 4:30 PM, Dan Korostelev wrote: > 2009/3/6 Tres Seaver : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Martijn Faassen wrote: >>> Hey, >>> >>> Laurence Rowe wrote: >>> [snip] It seems there is a 'tests_require' >>> >>> One reason that isn't used is that apparently there is no way for >>> us to >>> dig up this information in the way our test runner needs, unlike >>> extras >>> requires. >> >> If the testrunner would require 'eggtestinfo', and introspect the >> extra >> data it records, this wouldn't be true any longer. > > +1. Though, if that "eggtestinfo" package is really tiny, as I believe > it is, we could just copy it into the testrunner not to create extra > dependencies. (http://pypi.python.org/pypi/eggtestinfo) I skimmed the docs, but they were written generically, so I couldn't confirm: Tres, is this the thing that lets you run ``setup.py test`` against zope.testing, if you configure it properly? The last example seemed like that was it. If so, +1 on getting this into zope.testing, or at least this pattern into our standard ways of writing tests. IME, that's what non-Zope Python developers expect (as Tres has argued before). It's a small thing, but would get the non-Zope Python developer's experience off on the right foot. Tres, you've obviously done the research here to know: can we easily change zope.testing to make that story work? Or would you say that eggtestinfo is still a better/easier way to go about it, at least for now? Gary ___ 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] Python3 and attribute annotations.
On Mar 9, 2009, at 5:20 PM, Dan Korostelev wrote: > Hi zope developers! > > As you may know, python 3 introduced the concept of annotations for > callable objects. That annotations store information about arguments > and return values, which is kinda nice language feature that will > allow us to do interesting things. > > But there's a problem: those annotations will be stored in object's > __annotations__ attribute, which is also used by zope.annotation's > AttributeAnnotation implementation, so they will conflict. > > I think that it's a good time now to start thinking about problems > like this, because there's a lot of time before zope will be used in > python 3.0, so we can prepare to move without much problems. > > So, I propose to change annotation storage attribute to > "__zope_annotation__" and make AttributeAnnotation adapter > automatically migrate data from __annotations__ to > __zope_annotations__. I think that adding "zope" to the attribute name > will avoid any name clashes in future. > > I'd like to hear about problems that this change can possibly > introduce (__slots__, security proxies, etc.) and maybe some more > community ideas on that. Hi Dan. Thanks for bringing this up. If we do make changes for this purpose, I'd like to no longer use the __*__ pattern. When Zope 3 used the pattern initially, Python was not clear on its usage. Since then, it has clearly stated that the language claims __*__. While your proposal (__zope_*__) would almost certainly avoid a clash, I'd prefer to stick to the letter of the (new) law. I'd prefer "_z_*" or "_zope_*" or "_z_*__" or some other variation. (The ZODB usues _p_*, of course; I am inclined to _z_* because of the parallel and because it is short.) (If you are interested in the Python "waffle" when Zope 3 was written and the current language reference/PEP 8 , see my blog post this from February: http://codesinger.blogspot.com/2009/02/dont-use-in-python-unless-you-are.html . It may come off more strongly than it should, but I still find the point to be a good one.) Gary ___ 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: > Hi, > > I *think* this is a bug in zc.relationship, but I'm not quite sure. > > I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install > plone.app.relations, which depends on zc.relationship 1.0.2. In > particular, it subclasses zc.relationship.shared.Container, and > stores > a zc.relationship.index.Index object in self.relationIndex. > > Now, the __init__ of zc.relationship.index.Index, which derives from > Persistent, contains the code below. In self._relTools and and > self._attrs, there are a pile of modules, types and functions being > stored. I think these are causing the ZODB to barf. Interestingly, > with > whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no > problem. > > Any ideas how to work around this, or even why it's a problem in one > version of the ZODB but not another? No idea yet. What's the barf's traceback? Gary ___ 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 8:39 AM, Martin Aspeli wrote: > Gary Poster wrote: >> On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: >> >>> Hi, >>> >>> I *think* this is a bug in zc.relationship, but I'm not quite sure. >>> >>> I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install >>> plone.app.relations, which depends on zc.relationship 1.0.2. In >>> particular, it subclasses zc.relationship.shared.Container, and >>> stores >>> a zc.relationship.index.Index object in self.relationIndex. >>> >>> Now, the __init__ of zc.relationship.index.Index, which derives from >>> Persistent, contains the code below. In self._relTools and and >>> self._attrs, there are a pile of modules, types and functions being >>> stored. I think these are causing the ZODB to barf. Interestingly, >>> with >>> whatever version of ZODB that comes with Zope 2.10 (3.7?), there's >>> no >>> problem. >>> >>> Any ideas how to work around this, or even why it's a problem in one >>> version of the ZODB but not another? >> >> No idea yet. What's the barf's traceback? > > Mmmm... it seems that zc.relationship 1.1 fixes the issue, but has > some > other problems (an undefined variable minValues or similar - I haven't > got a build with this version in it right now); OK. > 2.0dev seems better, > albeit a bit scary at pre-alpha. zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation code for backwards compatibility. You guys are the main clients for zc.relationship at this point, I suspect. As I see it, your relatively reasonable options are these: - MOST WORK: Move the plone.relation code to depend on zc.relation. There is an upgrade path for the old indexes. You would need to copy over the old zc.relationship relationship containers to the Plone package. IIRC, Alec's tests of those bits were good, and you could just keep the bits from zc.relationship you needed. ZODB module path issues in legacy databases would be among the more annoying bits of this approach, though we all know the usual solutions there. - LESS WORK: See how zc.relationship trunk works for you. If it makes the code happy, I can release it or help you to do so. It's certainly been sitting around long enough. Then at least you are sitting (indirectly) on top of zc.relation, the package that (for instance) Martijn F.'s Grok work exercises. This would be my preferred compromise between effort and migration. The problem here is that it probably does depend on ZODB 3.8, and I'd rather not make the zc.relation code support the older spellings, so that's probably out for you unless you want to make a concrete counter-proposal in this regard. - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What you described sounds trivial to fix, and I don't have any ethical issues over only supporting the most recent release of the 1.x line, so I don't want to think about the earlier releases. I suspect this is what you want. We can make a 1.1.1 release and you can move on. Gary ___ 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 9:19 AM, Martin Aspeli wrote: > Hi Gary, > >> zc.relationship 2.0 trunk is now essentially a wrapping of >> zc.relation >> code for backwards compatibility. > > I see. But 2.0dev on pypi isn't? > > What's the story behind zc.relation and the evolution of > zc.relationship? Briefly, I wanted a package that only included the bit I used, the index (in zc.relation, the catalog). I abstracted it, made sure that zc.relation had 100% test coverage, and changed the names and the API in a backwards incompatible way. I also added a bunch of new features, like a transitive index for hierarchies. See http://pypi.python.org/pypi/zc.relation#changes for details. zc.relationship trunk then depended on zc.relation, and existed to provide backwards compatibility while not forcing me to maintain two versions of the same codebase. The upgrade path that the zc.relation PyPI doc describes from a zc.relationship index to a zc.relation index has been used in production, IIRC, but it requires zc.relationship trunk. I would be quite happy to release zc.relationship trunk as 2.0, if it helped you: it was used in production. If the ZODB 3.8-only issue is not a show-stopper then that's a good approach, and hopefully pretty easy for everyone. >> You guys are the main clients for zc.relationship at this point, I >> suspect. > > Possibly, yes. ;-) > >> As I see it, your relatively reasonable options are these: >> >> - MOST WORK: Move the plone.relation code to depend on zc.relation. >> There is an upgrade path for the old indexes. You would need to copy >> over the old zc.relationship relationship containers to the Plone >> package. IIRC, Alec's tests of those bits were good, and you could >> just keep the bits from zc.relationship you needed. ZODB module path >> issues in legacy databases would be among the more annoying bits of >> this approach, though we all know the usual solutions there. > > I think we'd need Alec to find the time to do this if it's to happen, > but it does sound like the better option. Perfect world, sure. >> - LESS WORK: See how zc.relationship trunk works for you. If it >> makes >> the code happy, I can release it or help you to do so. It's >> certainly >> been sitting around long enough. Then at least you are sitting >> (indirectly) on top of zc.relation, the package that (for instance) >> Martijn F.'s Grok work exercises. This would be my preferred >> compromise between effort and migration. The problem here is that it >> probably does depend on ZODB 3.8, and I'd rather not make the >> zc.relation code support the older spellings, so that's probably out >> for you unless you want to make a concrete counter-proposal in this >> regard. > > Well, having a version that only works with ZODB 3.8 isn't *terrible*, > it's just annoying. If and when Plone actually ships with five.intid > and > plone.relations, it'll be on ZODB 3.8 anyway. It's just a bit more > work > for people wanting to use it. Gotcha. Your choice. FWIW, this was the path I intended/hoped you guys would follow when I did the work to make zc.relationship sit on top of zc.relation. >> - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What >> you described sounds trivial to fix, and I don't have any ethical >> issues over only supporting the most recent release of the 1.x line, >> so I don't want to think about the earlier releases. I suspect this >> is what you want. We can make a 1.1.1 release and you can move on. > > Hopefully. Do we know that zc.relationship 1.1 works with both ZODB > versions? That would be a significant point of its existence, so I certainly hope so. I'm 80%+ confident that it does, and would regard not supporting 3.7 as a bug that I'd be willing to fix. > What's the difference between 1.1.1 and 2.0dev on pypi? I intended that 1.1.1 would simply make the absolutely minimal changes necessary for you to be able to use the 1.1 branch. It would not have any of the 2.x changes at all. Gary ___ 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 10:21 AM, Martin Aspeli wrote: > Hi Gary, > > Thanks for being so helpful! Happy to. >>> What's the difference between 1.1.1 and 2.0dev on pypi? >> >> I intended that 1.1.1 would simply make the absolutely minimal >> changes >> necessary for you to be able to use the 1.1 branch. It would not >> have >> any of the 2.x changes at all. > > But we're saying that 2.0dev is a very different beast to the trunk > that > could eventually become 2.0, right? 2.0dev doesn't have a zc.relation > dependency, for example. Yes. They are related, of course, but practically significantly different. > I'm not sure what else there may be in 2.0dev that's useful, of > course. Honestly, I'm not sure about the alpha any more either, though IIRC I did do a reasonable job on the change logs, so we could figure it out. > I think we need to hear from Alec on what makes most sense for > plone.relations. I care pretty much only about the plone.relations > API, > so I'm sure either of your three options could work. However, I have > no > idea how hard it'd be in practice to move closer to zc.relation. Sure. My hope is that switching to zc.relationship trunk (2.0) would be a drop-in change. Otherwise, 1.1(.1) definitely should be (with whatever necessary bug fixes). Let me know how I can help, once you all decide what direction you want to go. Gary ___ 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] setting missing minimum version in setup.py
On Mar 16, 2009, at 12:05 PM, Dan Korostelev wrote: > 2009/3/16 Martijn Faassen : >>> There is a compromise I am willing to take. If package zope.bar >>> depends on a >>> *new feature* or *feature change* in zope.foo 1.3.x, then it >>> should specify >>> the version. In other words specifying open restrictions on the >>> major version >>> levels is okay, but never on the bug fix level. (I just hope this >>> does not >>> bite us later. ;-) >> >> Yes, I was thinking in this direction too. I can see this as more >> of an >> issue with bug fixes than with feature changes. This means that >> requirements can only say zope.foo >= x.y, and never zope.foo >= >> x.y.z. >> >> What do people think? > > That looks sane, so I'm +1 :) Also +1 Gary ___ 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 1:20 PM, Martin Aspeli wrote: > Martin Aspeli wrote: >> Gary Poster wrote: >> >>>> Hopefully. Do we know that zc.relationship 1.1 works with both ZODB >>>> versions? >>> That would be a significant point of its existence, so I certainly >>> hope so. I'm 80%+ confident that it does, and would regard not >>> supporting 3.7 as a bug that I'd be willing to fix. >> >> Right... so I've just fixed the errors Pyflakes found with >> zc.relationship 1.1 branch. This now works reliably for my ZODB >> 3.8.1 build. >> >> However, it won't install in my ZODB 3.7 environment, because of this >> line in setup.py: >> >> 'ZODB3 >= 3.8dev', >> >> Was that an intentional minimum? > > Okay... so, if we remove that restriction, and add the following > monkey > patch to (which is already in plone.relations) to __init__.py, then > this > works on ZODB 3.7 with Zope 2.10, and the tests pass (save for > cosmetic > doctest failures on 3.7 which are easy to fix): > > # A tiny monkey patch due to some re-organization of future BTree > modules > try: > from BTrees.OOBTree import BTree > except ImportError: > import BTrees.OOBTree > import BTrees.IOBTree > import BTrees.OIBTree > import BTrees.IIBTree > import BTrees.IFBTree > BTrees.OOBTree.BTree = BTrees.OOBTree.OOBTree > BTrees.OOBTree.Set = BTrees.OOBTree.OOSet > BTrees.OOBTree.Bucket = BTrees.OOBTree.OOBucket > BTrees.OOBTree.TreeSet = BTrees.OOBTree.OOTreeSet > BTrees.IOBTree.BTree = BTrees.IOBTree.IOBTree > BTrees.IOBTree.Set = BTrees.IOBTree.IOSet > BTrees.IOBTree.Bucket = BTrees.IOBTree.IOBucket > BTrees.IOBTree.TreeSet = BTrees.IOBTree.IOTreeSet > BTrees.OIBTree.BTree = BTrees.OIBTree.OIBTree > BTrees.OIBTree.Set = BTrees.OIBTree.OISet > BTrees.OIBTree.Bucket = BTrees.OIBTree.OIBucket > BTrees.OIBTree.TreeSet = BTrees.OIBTree.OITreeSet > BTrees.IIBTree.BTree = BTrees.IIBTree.IIBTree > BTrees.IIBTree.Set = BTrees.IIBTree.IISet > BTrees.IIBTree.Bucket = BTrees.IIBTree.IIBucket > BTrees.IIBTree.TreeSet = BTrees.IIBTree.IITreeSet > BTrees.IFBTree.BTree = BTrees.IFBTree.IFBTree > BTrees.IFBTree.Set = BTrees.IFBTree.IFSet > BTrees.IFBTree.Bucket = BTrees.IFBTree.IFBucket > BTrees.IFBTree.TreeSet = BTrees.IFBTree.IFTreeSet > > > Shall I just check that in + the removal of the minimum version pin? Yes, +1. Thank you. I was about to write to your other message that this was quite possibly the only 3.8 dependency. > If we do that, then we can let plone.relations depend on > zc.relationship > 1.1.1 explicitly and have support for both ZODB versions, which > would be > nice. Sounds great. Would you like access to the PyPI zc.relationship record so you can upload the new version? If so, are you "optilude" there? Gary ___ 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 10:55 PM, Martin Aspeli wrote: > Gary Poster wrote: > >> Yes, +1. Thank you. I was about to write to your other message that >> this was quite possibly the only 3.8 dependency. > > Cool. Committed. > >>> If we do that, then we can let plone.relations depend on >>> zc.relationship >>> 1.1.1 explicitly and have support for both ZODB versions, which >>> would be >>> nice. >> >> Sounds great. Would you like access to the PyPI zc.relationship >> record so you can upload the new version? If so, are you "optilude" >> there? > > That'd be great, yeah. Or else, if you want to tag a release from the > 1.1 branch, that should be safe (and even less work for me :-) OK. I changed setup to fix the tests with the most recent packages, made a tag and release, and gave you access to the PyPI package just in case. Gary ___ 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] Please use launchpad bugtracking/blueprints more
On Mar 25, 2009, at 11:52 AM, Sidnei da Silva wrote: > Hi Martijn, > > On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen > wrote: >> One question is what launchpad project we should use. >> >> The current launchpad is for "Zope 3". The steering group isn't about >> Zope 3. It's about a whole bunch of libraries. Creating a separate >> launchpad project for each library in the framework seems like a >> bit of >> overkill at this stage, though it would please those people who >> come at >> us at the perspective from libraries the most. > > It smells like 'Zope Framework' (zope-framework) should be a Project > Group then, and there should be a 'Zope Steering Group Project' > (zope-steering-group-project) as part of it, and sibling of Zope 3 and > any other libraries that are part of Zope Framework. For an example of > what this looks like, look at: > > https://launchpad.net/chameleon-template-engine > > I can help setting up this structure, if needed. I agree with Sidnei. Another example is the lazr projects (https://launchpad.net/lazr ). To be clear, making an umbrella project like this does need someone with admin rights in lp, so it will need "help" if it is desired. :-) Gary ___ 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] PyCon?
On Mar 24, 2009, at 6:12 AM, Chris Withers wrote: > Hey All, > > Who's around at PyCon? If so, when/where are we meeting up? Arriving Thursday evening, leaving following Thursday afternoon. I'm starting at the Hyatt, going to the Crowne Plaza on Monday. Email is maybe the best public way to get in touch with me, though I'm happy to share cell phone/skype info privately. Gary ___ 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] Please use launchpad bugtracking/blueprints more
On Mar 25, 2009, at 2:21 PM, Martijn Faassen wrote: > Sidnei da Silva wrote: >> Hi Martijn, >> >> On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen >> wrote: >>> One question is what launchpad project we should use. >>> >>> The current launchpad is for "Zope 3". The steering group isn't >>> about >>> Zope 3. It's about a whole bunch of libraries. Creating a separate >>> launchpad project for each library in the framework seems like a >>> bit of >>> overkill at this stage, though it would please those people who >>> come at >>> us at the perspective from libraries the most. >> >> It smells like 'Zope Framework' (zope-framework) should be a Project >> Group then, and there should be a 'Zope Steering Group Project' >> (zope-steering-group-project) as part of it, and sibling of Zope 3 >> and >> any other libraries that are part of Zope Framework. For an example >> of >> what this looks like, look at: > > Why would the steering group be a project as part of the Zope > Framework? > The steering group isn't a project? > > I'm all for setting something up, but I'm still not clear on what > you'd > set up. A Zope Framework project group with what inside? My take would be the following. It's probably contentious. - The current zope3 project is regarded as a project for the aggregation of the pieces into the old tgz and the old mgmt UI. This should be clarified on the project page. - There is a new Zope Framework (I would prefer Zope Libraries myself, but let's not start that again ;-) ) umbrella project, controlled by a new Zope Framework team. - There are multiple zope.* (and z3c.* and whatever) library projects. They are part of the umbrella project (if so desired by the pertinent parties). - The current zope3 project should be considered part of the Zope Framework *at least for now* because it has legacy information. If someone reassigns the bugs and blueprints and so on to the pertinent library projects (or to the Zope Framework), "zope3" could no longer be part of the Zope Framework umbrella project, if desired. That's work, though, so I'd be inclined to see if it happens and meanwhile be happy to take the zope3 project in as legacy. Gary ___ 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] Zope Source Code Repository
On Apr 2, 2009, at 1:31 PM, Chris Withers wrote: > Hey All, ... > The other option would be to follow Python and move to Mercurial, but > that has the same problems for me as with Bzr (no decent gui tools, > less > mature, etc) although it's a toolset I'll have to learn at some point > anyway... I'd like to report back on the progress that Bzr/Launchpad has made addressing concerns we heard since I last brought up Canonical's offer to host the code and contribute commercial support for the transition. When I do that, I'll do it on zope-dev, assuming that Tres' statement in this thread that we should discuss there is authoritative. (I thought the people on Foundations were the superset of people who commit to the repo, but I guess I was mistaken. Sorry for my misunderstanding.) However, I just got back from a long trip, and I'm going to spend some time with my family. I'll write something up to zope-dev tomorrow. Gary ___ 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] Zope Source Code Repository
On Apr 2, 2009, at 7:35 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Gary Poster wrote: > >> I'd like to report back on the progress that Bzr/Launchpad has made >> addressing concerns we heard since I last brought up Canonical's >> offer >> to host the code and contribute commercial support for the >> transition. [snip saying I'll do it later, and apology for misunderstanding of Foundation membership] > The foundation members are a *subset* of all committers, with > sponsoring > companies added on. There are under 50 "nominated members" (formerly > "committer members", whereas there are something like 375 committers. > > Any decision to move the repository will need to be formally made by > the > foundation (via its board), but that would only happen if the > consensus > of the members and the wider community were clearly in favor of a > move. Good to know, thank you. Off to write the email... Gary ___ 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] Constant values defined in interfaces
On Apr 3, 2009, at 12:35 PM, Chris Rossi wrote:
> Hello,
Hi Chris.
>
> I was wondering if the Zope collective had given any consideration
> to allowing constants to be defined in interfaces. To be clear,
> these are constant values that make up the protocol defined by the
> interface.
...
FWIW, interfaces.py is often regarded as a contract itself. A current
best practice is to define constants and exceptions in that file, and
import them from the module.
> If this hasn't been done yet, I can envision doing something like:
>
> from zope.interface import Constant
>
> class IHttpResponse(Interface):
> """Models an HTTP 1.1 response.
> """
> HTTP_OK = Constant("200 Ok", "An HTTP Ok response.")
> HTTP_NOT_FOUND = Constant("404 Not Found", "An HTTP Not Found
> response")
>
> status = Attribute("HTTP status code for this response.")
How would that be a win for you (or anybody else) over just putting
the constant in the interfaces module?
If it is in the interface, that implies we need to "implement" it
someplace--the constant will be defined in the interface and in the
implementation? Or we would offer automation to copy the values over
from the interface to objects that implement the interface?
> Using descriptors, the results could be both static and immutable.
Mostly static and immutable, anyway. :-) In Python, there's almost
always a way around absolutes like that unless you are working with
something in which the constraint has been coded in C.
I don't find enforcing a constant's immutability in any way other than
relying on a programmer's good sense to be particularly valuable. I
have sympathy for "enterprise-y" concerns, in which you have some belt-
and-suspenders--we use security proxies for that kind of thing, and
appreciate them despite their added pain--but I don't see how a
programmer might "forget" to not overwrite an ALL_CAPS constant.
And finally, this "Constant" constructor would control the interface,
not the implementation, so you'd have to do the static/immutable
things elsewhere.
So, I'm -1 on "Constant" unless someone gives a convincing reason why
it is preferable to putting constants in the module, in which case I
will suddenly have a polar shift to +0. :-)
Gary
___
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] Constant values defined in interfaces
On Apr 3, 2009, at 2:14 PM, Chris Rossi wrote: > > > On Fri, Apr 3, 2009 at 1:55 PM, Gary Poster > wrote: > > How would that be a win for you (or anybody else) over just putting > the constant in the interfaces module? > > Standard practice seems to favor putting several interfaces in a > single "interfaces" module, so just putting the constants in the > module doesn't make it explicit that these constants go with a > particular interface. Putting them on the interface itself makes > the relationship plain. True. FWIW, I usually do that in the text of the interface if I need to, but I absolutely see where you are coming from. > If it is in the interface, that implies we need to "implement" it > someplace--the constant will be defined in the interface and in the > implementation? Or we would offer automation to copy the values > over from the interface to objects that implement the interface? > > > Thanks for bringing that up. I hadn't considered that. In > languages with built-in interface support, classes generally > inherent constants from the interface, so automatically copying the > values over would seem to make sense. Although it's also considered > best practice in those languages to refer to the constants by their > interface anyway, so one could argue that such a step could be > omitted. Zope's implementation of interfaces is unique among > implementations I know about, in allowing programmers to mark live > objects with an interface, which would introduce an interesting edge > case with regards to copying constants over. I'd say if the > implementation gets too polluted with edge cases, it's probably not > worth it. Agree. > Using descriptors, the results could be both static and immutable. > > Mostly static and immutable, anyway. :-) In Python, there's almost > always a way around absolutes like that unless you are working with > something in which the constraint has been coded in C. > > Right, but since we have descriptors, why not use them? Maybe I > should have used the Colbertian "immutablish". :-) Yeah, ok. > I don't have my heart set on this. I found a use case today and was > just thinking about ways to satisfy it. If there's a reasonable story for the connection between interfaces and the objects providing them (that is, what we talked about above), then I wouldn't object. I don't know what that reasonable story might be, though. Gary ___ 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] Constant values defined in interfaces
On Apr 3, 2009, at 7:21 PM, Wichert Akkerman wrote: > This looks like a poor man's enum. I'ld prefer to have a proper enum > like thing. Seems a little different to me. For what it is worth, though, if you do want an enum in zope.schema, Canonical has lazr.enum: http://pypi.python.org/pypi/lazr.enum . Gary ___ 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] Zope Source Code Repository
On Apr 6, 2009, at 6:51 AM, Chris Withers wrote: > Martijn Pieters wrote: >> On Mon, Apr 6, 2009 at 11:53, Wichert Akkerman >> wrote: Note that we are now up to svn 1.6. >>> Which still does not fix this, and is preventing people from >>> upgrading >>> to the 1.5 client, and thus from using checkouts using relative >>> paths. >> >> Bugger, that is indeed correct. I may not have any problems (and a >> workaround for svn bug 3119) but that doesn't mean we can ask other >> people that need access to more tightly ACL-ed repositories to put up >> with subversion 1.5 and 1.6. > > To be honest, the state of svn 1.5 is what's getting me to think about > looking at mercurial. > > (bzr didn't take my fancy, and hg is gonna be used by the python-core > folks, so I might as well learn that...) > > Sadly, I suspect none of the tools are as advanced as TortoiseSVN. > Which > is a real shame :-( Perforce maybe? ;-) Fair enough that bzr didn't take your fancy, but FWIW, did you try TortoiseBzr? That has received love relatively recently. Gary ___ 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] Zope Source Code Repository
On Apr 6, 2009, at 9:28 AM, Chris Withers wrote: Gary Poster wrote: Sadly, I suspect none of the tools are as advanced as TortoiseSVN. Which is a real shame :-( Perforce maybe? ;-) Fair enough that bzr didn't take your fancy, but FWIW, did you try TortoiseBzr? That has received love relatively recently. I'm looking at this: http://bazaar-vcs.org/TortoiseBzr/Screenshots Where's the visual diff? Where's the interactive log of revisions? Where's the repository browser? FWIW, I don't know if TortoiseBzr has this. I'd be surprised if it didn't have these, especially the first two. It would be cool if someone with easy access to Windows were to check this out. Otherwise, I'll give it a try eventually and report back myself. (If it has these features, I'll try to figure out someone to ask to get that page updated.) Does it work the same on Windows, Ubuntu and Mac OS? (I assume you mean bzr vs.svn, rather than TortoiseBzr vs. TortoiseSvn; AFAICT, Tortoise* is Windows only.) Well, the EOL problem has been the only bzr kicker there. That was just addressed, spurred most recently in part because of the concerns from the Zope community; I don't know if it is in 1.13 or the upcoming 1.14. Other than that, I think bzr cares a fair amount about Windows (and certainly about Ubuntu and Mac). http://tortoisesvn.net/image/tid/13 gives a fair idea of the kinds of things I'd need to feel compelled to change... Right. Looks nice enough. Gary___ 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] Defining Zope 3.
On Apr 15, 2009, at 11:28 AM, Lennart Regebro wrote: > Here are a list of things I have seen that you may mean when you say > "Zope 3". I'm sure I missed several: > > 1. Whatever is included in the Zope 3 tgz that you download. > > 2. All the packages included in the Zope 3 KGS. (Should be the same as > 1, if I understand correctly.) > > 3. 1 or 2 minus the ZMI. > > 4. The zope.app.publication publisher. > > 5. A loose set of packages starting with zope.*, zc.* and z3c.* > > 6. A strictly defined (by the Zope Toolkit KGS) set of packages > starting with zope.*, zc.* and z3c.* that is central and common to > Zope 3 in the sense of 1 or 2, and also Grok and Zope 2. > > 7. Technologies that you use when you develop with the packages in 5 > and 6. > > > I propose that the name Zope 3 applies *only* to 1 and 2. If future > versions of 1 or 2 gets released without the ZMI (as discussed in > other threads), then of course 1, 2 and 3 is the same. > > Opinions? I've been away on a vacation of sorts, and find myself happy to not have been around for this firestorm. A few observations. - I very much agree with Lennart's observation that the definition of "Zope 3" is not clear. - It may have been a mistake to use the name "Zope 3", but it is done now, and done a *long* time ago. Trying to outright kill it feels like thrashing. - Moreover, because *we* don't know what "Zope 3" means, I'm afraid users outside viewers are going to easily misinterpret any kind of message framed in the terms of "Zope 3's death" or "abandonment" or whatever.How are they supposed to know what it means? I was concerned about Tim Hoffman's statement in the long "who wants to maintain..." thread: "It seems from all the discussion of late that we might of chosen a architectural dead end (though I don't think so)." We're not declaring the Zope 3 libraries (toolkit, whatever, bah) a dead end; far from it. But how easy it is to make a sound bite from this discussion into basically that message? "Zope 3: architectural dead end." I don't care for that, myself, nor do I find it accurate. This message seems like a reasonable start to me: "Zope 3 has become focused on supporting frameworks and applications, rather than trying to be one itself. It is now called the Zope Toolkit. Parts of it are used by Zope 2, Plone, Grok, Repoze.bfg, and by many other different applications and frameworks." That message implies two things to me. First, to start with, this is just a rename. Zope 3, as defined by the KGS, becomes the Zope Toolkit. Second, the "Zope Toolkit" is about supporting other frameworks. That means that it is reasonable to expect that the packages and the parts of packages that were about the ZMI will quite possibly die a typical open source death of not enough people caring anymore. I don't think trying to guess which parts or packages will die is a particularly useful exercise. The community will support what the community supports...as usual. This is open source. You're gambling that enough other people will be there with you to make it worthwhile, and you may be required to step up with money or talent or energy to make that happen. So, again, in sum, I propose that this discussion should simply be reduced to a rename to start with: Zope 3, as defined by the KGS -> Zope Toolkit. The software switch that this name change implies has started quite some time ago, with the eggification, and will continue in its natural and usual open-source course. Gary ___ 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] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues
I'm concerned about the state of the zc.buildout template recipes. I want one. I want some one-off files, specific to a certain project, for which writing a standalone recipe feels very heavy. Here are the template recipes I found: collective.recipe.template (Wichert Akkerman) iw.recipe.template (Ingeniweb) inquant.recipe.textfile (Stefan Eletzhofer) z3c.recipe.template (Uli Fouquet) buildout_script (Nathan Yergler) z3c.recipe.filetemplate (Philipp von Weitershausen) First, on the basis of this list, it strikes me that a lot of people want this functionality. Putting template support into zc.buildout itself would be nice. I envision some APIs (like the ones in easy_install.py that zc.recipe.egg uses) that other recipes could use easily. I would even want recipes like the zc.recipe.egg script recipe to allow specifying initialization code by identifying a template (i.e., ``initialization_template = buildout_templates/foo``, which would parse the given template and insert the code the same way the ``initialization`` parameter works). Second, there's no clear winner at the moment. I happened to find z3c.recipe.template, buildout_script, and z3c.recipe.filetemplate first. On the basis of those three, and the comments that z3c.recipe.template made about collective.recipe.template, iw.recipe.template, and inquant.recipe.textfile, I decided to settle on z3c.recipe.template to be the package to which I would contribute. It has tests, a variable substitution approach that seems to work well with buildout, and recent development activity. However, on starting to hack on its documentation to sketch the changes I wanted, I gradually realized that this was a fork of collective.recipe.template. Since collective.recipe.template is listed as BSD in setup.py (though I saw no explicit licensing otherwise), placing z3c.recipe.template in the zope.org ZPL-only repository is problematic. Since I don't find the prospect of creating yet another template recipe attractive, and Philipp's z3c.recipe.filetemplate looks like it can take my new features while maintaining backwards compatibility, I'll try that next, I suppose. But meanwhile, I'm concerned about the state of z3c.recipe.template. IMO, Uli and Wichert should try to reconcile the licensing and forking issues (with Uli taking the lead in those discussions, ideally, since he is the one who forked). z3c.recipe.template should be removed from the zope.org repository, unless/until the licensing story is cleaned up. And maybe we can start to settle on a common template approach soon. This should be a problem that is solved for buildout canonically, IMO. I'll be happy to try and see if my features are generally interesting, once I make them. (Note: I could write about this on the distutils list but I'm not already subscribed there, and I suspect I have a better chance of catching some authors of the pertinent recipes over here, and some of this is about the zope.org repo.) Gary ___ 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] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues
Thanks Uli, Wichert, and Hanno for working out the legal bits! And
thanks to Martijn and Martin for the other replies.
On Friday I had moved to z3c.recipe.filetemplate, for the reasons I
had described then. Philipp said I could run with that package.
However, I'd prefer to work with a more active project. If there's
quick agreement on my additions to the collective recipe, and I'm
given commit access, I'll switch. I don't have time for a bikeshed
discussion though, so if it descends much into that I'll stick with
extending Philipp's recipe for now, and maybe switch over later when
things settle down.
If I built on collective.recipe.template, I'd make the following
changes.
REQUIRED
- verify that the BSD licensing rules are followed (headers, license
inclusion, copyright statement, etc.), and fix if not. I'd prefer if
a foundation (e.g., the Plone Foundation) had the copyright. (TBH,
I'm more comfortable with the Zope Foundation repository because the
rules for copyright assignment are clearer AIUI, even if they are
breached sometimes, as was this case here. But this isn't critical
for my usage or contribution.)
- Add the ability to specify "eggs" and "extra-paths" the way you can
for scripts. These supply the values for three predefined options
(available to the template). If "paths" are the non-zip paths, and
"all_paths" are all paths, then the options woud be defined roughly as
given here:
os-paths: (os.pathsep).join(paths)
string-paths: ', '.join(repr(p) for p in all_paths)
space-paths: ' '.join(paths)
- I have a directory of *.in files that will need to be processed,
with shared options, and put in another directory. Therefore, I'd
like to be able to just specify the input directory and optionally the
output directory. globs, for filters, might be a nice-to-have. I came
up with a spelling for all this that appealed to me for Philipp's
package (which has a constraint of "I only use *.in inputs, and always
strip ".in" for the output). WIth my variant of his spelling, I could
do everything I wanted with a line like
files = *
source-directory = templates
Then in ``templates`` you would arrange the directory structure you
wanted, and make sure that your template files end with ".in".
I don't have a spelling I like as much for the "input" "output"
pattern of the collective recipe. I'd be OK with "input" and "output"
being able to take multiple files:
input = templates/etc/foo.in
templates/etc/bar.in
output = etc/foo
etc/bar
That seems like it rocks the boat least for collective.recipe.template
NICE-TO-HAVE
Unless I discover I need this, these are just ideas that I might do on
hobby time.
- Extend/override other buildout sections. Here's an example, with
Philipp's package. Consider the following buildout::
>>> write(sample_buildout, 'buildout.cfg',
... """
... [buildout]
... parts = message
...
... [template_defaults]
... mygreeting = Hi
... myaudience = World
...
... [message]
... recipe = z3c.recipe.filetemplate
... files = helloworld.txt
... extends = template_defaults
...
... myaudience = everybody
... """)
The "message" section now has values extended from the
"template_defaults"
section, and overwritten locally. A template of
``${mygreeting}, ${myaudience}!`` would thus result in ``Hi, everybody!
``.
- Define option values in Python. This would have the os and sys
modules in the namespace, and would also have the buildout variables,
and would have the paths and all_paths from the ``eggs`` section above
so you could manipulate them as desired.
interpreted-options = path-separator=os.pathsep
example-paths=' '.join('-t%s' %
p for p in paths)
That would put ``path-separator`` and ``example-paths`` in the
recipe's options.
- Make a script recipe that allows you to specify an
``initialization_template``, as I described in my first email.
I'm pretty busy all around right now, and there's always the YAGNI
concern, so I probably won't do those, but they seem like potentially
good ideas.
Gary
___
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] [Feature Request] add 'extensions' option to z3c.recipe.sphinxdoc
Hi Markus. Stephan Richter and Paul Cardune are the people I would expect to manage this package. I expect they'll get back to you soonish. On freenode #zope3-dev they are srichter and pcardune, IIRC. The feature and the diff look reasonable to me. Normally we want tests in our diffs, but this package doesn't have them yet, so I don't see why it should block this contribution. FWIW, I did notice a trivial issue: a spelling error in the CHANGES: "seperated" -> "separated". Thanks! Gary On Apr 28, 2009, at 9:25 AM, markus korn wrote: > I'm not familiar with your process of implementing new features, but > the attached patch adds such option to z3c.recipe.sphinxdoc, comments > welcome. > > Markus > < > add_extensions_option > .diff>___ > 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 )
Re: [Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues
On Apr 27, 2009, at 4:33 PM, Wichert Akkerman wrote: > Hi Gary, Hey Wichert. Sorry for not replying sooner. I had already gone pretty far down the z3c.recipe.filetemplate road, so I kept going over there. I just made a release. It is http://pypi.python.org/pypi/z3c.recipe.filetemplate if you are interested. I obviously learned a lot from your design. I wanted to get that release out before replying. > > Previously Gary Poster wrote: >> Thanks Uli, Wichert, and Hanno for working out the legal bits! And >> thanks to Martijn and Martin for the other replies. >> >> On Friday I had moved to z3c.recipe.filetemplate, for the reasons I >> had described then. Philipp said I could run with that package. >> However, I'd prefer to work with a more active project. If there's >> quick agreement on my additions to the collective recipe, and I'm >> given commit access, I'll switch. I don't have time for a bikeshed >> discussion though, so if it descends much into that I'll stick with >> extending Philipp's recipe for now, and maybe switch over later when >> things settle down. > > Commit access to the collective is very liberal and generally arranged > within 24 hours. Uli has both commit and pypi access for the package > and > has already done a lot of work on it. Your contributions are very > welcome as well! Thank you, excellent. If you want me to help migrating some of the z3c.recipe.filetemplate features over to the collective version, let me know. I'd like to cooperate. It would be strictly hobby-time work, though, and I have a marked reduction in that lately. :-/ Hopefully things will have calmed down by the fall. :-) > >> If I built on collective.recipe.template, I'd make the following >> changes. >> >> REQUIRED >> >> - verify that the BSD licensing rules are followed (headers, license >> inclusion, copyright statement, etc.), and fix if not. I'd prefer if >> a foundation (e.g., the Plone Foundation) had the copyright. (TBH, >> I'm more comfortable with the Zope Foundation repository because the >> rules for copyright assignment are clearer AIUI, even if they are >> breached sometimes, as was this case here. But this isn't critical >> for my usage or contribution.) > > The BSD license has very little restrictions. It certainly does not > require licens statementsin every source file or so. Personally I find > those to be clutter. If there is a missing license file that should be > fixed. I don't think the license is actually included in the collective recipe ATM. Maybe I misremember. But beyond that, BSD doesn't need headers, IIUC, so at least that's not necessary, yeah. > >> - Add the ability to specify "eggs" and "extra-paths" the way you can >> for scripts. These supply the values for three predefined options >> (available to the template). If "paths" are the non-zip paths, and >> "all_paths" are all paths, then the options woud be defined roughly >> as >> given here: >> >> os-paths: (os.pathsep).join(paths) >> string-paths: ', '.join(repr(p) for p in all_paths) >> space-paths: ' '.join(paths) > > I can see that being useful. Cool. > >> - I have a directory of *.in files that will need to be processed, >> with shared options, and put in another directory. Therefore, I'd >> like to be able to just specify the input directory and optionally >> the >> output directory. globs, for filters, might be a nice-to-have. I >> came >> up with a spelling for all this that appealed to me for Philipp's >> package (which has a constraint of "I only use *.in inputs, and >> always >> strip ".in" for the output). WIth my variant of his spelling, I >> could >> do everything I wanted with a line like >> >> files = * >> source-directory = templates >> >> Then in ``templates`` you would arrange the directory structure you >> wanted, and make sure that your template files end with ".in". >> >> I don't have a spelling I like as much for the "input" "output" >> pattern of the collective recipe. I'd be OK with "input" and >> "output" >> being able to take multiple files: >> >> input = templates/etc/foo.in >> templates/etc/bar.in >> output = etc/foo >> etc/bar >> >> That seems like it rocks the boat least for >> collective.
Re: [Zope-dev] tabs in the source
On Jun 22, 2009, at 1:16 PM, Adam GROSZER wrote: > Hello, > > Maybe it's time for an svn commit police squad? > 22 .py files have tabs... and I grepped only zope.* packages. FWIW, to state the probably obvious, other projects handle this with varying degrees of increased control. Some require one or more reviews before a commit (Launchpad and others support this--github maybe? I forget). Others require certain quality tests to pass before a branch is merged (I'm familiar with PQM or the upcoming Tarmac combined with bzr, but there are many many other posibilities, I'm sure). Others use buildbot for various tests, using the social embarrassment vector. Launchpad developers have ongoing experiments in this regard, currently combining all of the approaches. I've found them much better than commit police squads both in terms of what they catch and what kind of interaction they encourage. Jono Lange has a nice talk about code review, FWIW, with links to more (like Guido's old Mondrian video). http://mumak.net/stuff/your-code-sucks.html Gary ___ 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] zc.async: cron replacement?
On Jun 24, 2009, at 1:19 PM, Reinout van Rees wrote: > Hi all, > > In messages like http://www.mail-archive.com/zope3-...@zope.org/msg05964.html > , > zc.async is mentioned as the solution for cron-like functionality in > zope. > Effectively you would not need zope2's clockserver. > > Reading zc.async's docs, I cannot find how to do a given task > regularly. For > example a weekly pack. Or a daily call of one method that archives > older > items. That sort of stuff. Many things can be handled by cronjobs, > but you > tend to get a lot of them. And you don't want to embed the password > everywhere. > > Anyway: I cannot find the word "cron" anywhere in the zc.async > source. Or > "repetitive" or "regular". Is zc.async not intended for this kind > of usage? Hi Reinout. zc.async can be used to do cron-like activities by starting a job, to be performed after a certain time, that has a callback that reschedules another job when desired. This has the advantage over cron-like behavior because it does not reschedule until the first job is done. Other zc.async competitors have cron implemented more directly, but I found it to be very easy and flexible to do what I wanted using the zc.async approach. Gary ___ 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] time.sleep in a boolean check in zope.publisher.http.HTTPRequest.supportsRetry?
Two teams here at Canonical just encountered the STAGGER_RETRIES behavior in http://svn.zope.org/zope.publisher/trunk/src/zope/publisher/http.py?rev=101538&view=auto . I don't see anything in tests or comments to explain it. Our guess is that it tries to put some breathing room around retries so that the chance of a conflict error might be reduced. In one of our tests setting STAGGER_RETRIES to False reduced a test run from almost 9 minutes to about 1 minute (see https://bugs.edge.launchpad.net/launchpad-foundations/+bug/401586) . We have papered this over in our test suite to no ill effect, giving speed advantages. We wonder if we should remove the behavior entirely, even in production. 1) Why should the time.sleep go into supportsRetry rather than retry? it seems really odd to have it in the method that returns a boolean, rather than the one that does the work. 2) Can someone give some background for this code? Can they give examples of it actually helping anything? We'd like to improve this, minimally by adding some explanatory comments, and maybe by changing, moving, or removing this code. (If anyone tries to do an "annotate" on this, you'll see Jim checked this in back at the dawns of time in rev 8532. On IRC, he didn't recognize this code on a quick look, so he thinks someone else might be more familiar with this.) Gary ___ 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] time.sleep in a boolean check in zope.publisher.http.HTTPRequest.supportsRetry?
On Aug 20, 2009, at 1:50 PM, Jim Fulton wrote: > On Mon, Aug 17, 2009 at 1:43 PM, Gary Poster > wrote: >> Two teams here at Canonical just encountered the STAGGER_RETRIES >> behavior in >> http://svn.zope.org/zope.publisher/trunk/src/zope/publisher/http.py?rev=101538&view=auto >> . I don't see anything in tests or comments to explain it. Our >> guess is that it tries to put some breathing room around retries so >> that the chance of a conflict error might be reduced. > > Yup, although I think it's misguided in this case. With conflicts, > there's always a winner, so it makes sense to try again right away. > >> >> In one of our tests setting STAGGER_RETRIES to False reduced a test >> run from almost 9 minutes to about 1 minute (see >> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/401586) >> . We have papered this over in our test suite to no ill effect, >> giving speed advantages. We wonder if we should remove the behavior >> entirely, even in production. > > I think so. > >> 1) Why should the time.sleep go into supportsRetry rather than retry? >> it seems really odd to have it in the method that returns a boolean, >> rather than the one that does the work. > > Yup. > >> 2) Can someone give some background for this code? Can they give >> examples of it actually helping anything? > > I doubt it. > >> We'd like to improve this, minimally by adding some explanatory >> comments, and maybe by changing, moving, or removing this code. > > Let's just remove it. Cool, I'll do it tonight or tomorrow (have to run right now). Thank you very much! Gary ___ 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] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hm. I sent this from the wrong account, so it didn't make it to the
zope-dev list. I'm also adding an additional bit of war story at the
end.
On Aug 24, 2009, at 11:16 AM, Gary Poster wrote:
> Hi Tres
>
> I made a 3.5.8 release of the zope.publisher 3.5 branch for a reason
> unimportant to this email (I backported a change to trunk that was
> discussed on the mailing list). It looks like you made a 3.5.7 with
> the following change (omitting tests and the like).
>
> 98932tseaver # Python 2.6 notices QS-on-POST,
> which breaks BBB for us.
> 98932tseaver # Suppress that.
> 98932tseaver if 'QUERY_STRING' in self._environ:
> 98932tseaver env = self._environ
> 98932tseaver env['X-POST-QUERY_STRING'] =
> env.pop('QUERY_STRING')
>
> I can handle adjusting to this change, if it is appropriate, but my
> concern is that it is not in trunk or any subsequent major release
> (3.6, 3.7, 3.8) of zope.publisher. Therefore, if I change my code
> to use my updated 3.5 release, which I had hoped would be a
> conservative update, I have to change in a currently forward-
> incompatible way.
>
> What's the story here? Is 3.5.7 a brownbag that needs to have its
> changes aborted in a subsequent release in that branch? Or are
> those legitimate changes that need to be forward ported?
>
> FWIW, we (Launchpad) also care about this case of a POST with other
> pertinent, separate data in the query string, and the behavior you
> implement here would be fine if it is necessary for Py 2.6 as your
> comment describes.
Also FWIW, this change breaks many of our forms that were explicitly
constructing form actions that included the current query string. I'm
not sure how that could be avoided, although the fix might have been
simpler if there were always an X-ORIGINAL-QUERY_STRING or something
else.
If I were not already behind, I would investigate to understand the
Python 2.6 problem better and see what other frameworks are doing
here. I understand from conversations with other engineers that at
least some Django developers are accustomed to always having access to
the query string on the request object, whether the method were get or
post or whatever else.
>
> Gary
___
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] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
On Aug 24, 2009, at 5:27 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Gary Poster wrote:
>> Hm. I sent this from the wrong account, so it didn't make it to the
>> zope-dev list. I'm also adding an additional bit of war story at the
>> end.
>>
>>
>> On Aug 24, 2009, at 11:16 AM, Gary Poster wrote:
>>
>>> Hi Tres
>>>
>>> I made a 3.5.8 release of the zope.publisher 3.5 branch for a reason
>>> unimportant to this email (I backported a change to trunk that was
>>> discussed on the mailing list). It looks like you made a 3.5.7 with
>>> the following change (omitting tests and the like).
>>>
>>> 98932tseaver # Python 2.6 notices QS-on-POST,
>>> which breaks BBB for us.
>>> 98932tseaver # Suppress that.
>>> 98932tseaver if 'QUERY_STRING' in self._environ:
>>> 98932tseaver env = self._environ
>>> 98932tseaver env['X-POST-QUERY_STRING'] =
>>> env.pop('QUERY_STRING')
>>>
>>> I can handle adjusting to this change, if it is appropriate, but my
>>> concern is that it is not in trunk or any subsequent major release
>>> (3.6, 3.7, 3.8) of zope.publisher. Therefore, if I change my code
>>> to use my updated 3.5 release, which I had hoped would be a
>>> conservative update, I have to change in a currently forward-
>>> incompatible way.
>>>
>>> What's the story here? Is 3.5.7 a brownbag that needs to have its
>>> changes aborted in a subsequent release in that branch? Or are
>>> those legitimate changes that need to be forward ported?
>>>
>>> FWIW, we (Launchpad) also care about this case of a POST with other
>>> pertinent, separate data in the query string, and the behavior you
>>> implement here would be fine if it is necessary for Py 2.6 as your
>>> comment describes.
>>
>> Also FWIW, this change breaks many of our forms that were explicitly
>> constructing form actions that included the current query string.
>> I'm
>> not sure how that could be avoided, although the fix might have been
>> simpler if there were always an X-ORIGINAL-QUERY_STRING or something
>> else.
>>
>> If I were not already behind, I would investigate to understand the
>> Python 2.6 problem better and see what other frameworks are doing
>> here. I understand from conversations with other engineers that at
>> least some Django developers are accustomed to always having access
>> to
>> the query string on the request object, whether the method were get
>> or
>> post or whatever else.
>
> It is *essential* for correct operation that QUERY_STRING values *not*
> be admixed with POSTed form values. I don't really care how we
> resolve
> your issue, as long as we do not end up in a case where the values in
> the query string get mingled into the form data: for instance, we
> could
> hand a QUERY_STRING-free copy of the environment to the
> cgi.FieldStorage
> machinery.
>
> Whatever gets done needs to leave the existing test in place::
>
> self.assertEqual(dict(request.form), dict(x='1', y='2'))
>
> for a request whose QUERY_STRING was 'a=5&b:int=6', but which posted
> the
> 'x' and 'y' values.
I'm good with that.
My additional constraint would be that
self.assertEqual(request.get('QUERY_STRING'), 'a=5&b:int=6')
for the same request. Hiding the QUERY_STRING causes us some
unpleasant and subtle functional test pain.
Passing a QUERY_STRING-free copy to cgi.FieldStorage as you suggest
seems like a good way to go to me.
Unless someone beats me to it or stops me, I'll plan to make this go
in trunk and in the 3.5 branch, and make a 3.5.9 release.
(If someone *were* to beat me to it, that would be awesome. I'm kinda
swamped.)
Thanks
Gary
___
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] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote: > Hi Tres > >> Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has >> code/behavior not a part of subsequent releases > > [...] > >>> If I were not already behind, I would investigate to understand the >>> Python 2.6 problem better and see what other frameworks are doing >>> here. I understand from conversations with other engineers that at >>> least some Django developers are accustomed to always >> having access to >>> the query string on the request object, whether the method >> were get or >>> post or whatever else. >> >> It is *essential* for correct operation that QUERY_STRING >> values *not* be admixed with POSTed form values. I don't >> really care how we resolve your issue, as long as we do not >> end up in a case where the values in the query string get >> mingled into the form data: for instance, we could hand a >> QUERY_STRING-free copy of the environment to the >> cgi.FieldStorage machinery. > > As far as I understand, you are saying that it is essential > that posted data and a query string should be separated > for processing in python libraries e.g. FieldStorage or so. > > But this doesn't mean both values could not end in the > request.form dict right? right, that's what he wants, and that's the pre-Py 2.6 behavior. > >> Whatever gets done needs to leave the existing test in place:: >> >> self.assertEqual(dict(request.form), dict(x='1', y='2')) >> >> for a request whose QUERY_STRING was 'a=5&b:int=6', but which >> posted the 'x' and 'y' values. > > Was this supported before your changes? Is this a new feature > you decided to add? What's the reason for this? Can you point > me to more infos? The constraint is an old behavior. The solution in 3.5.8 and 3.5.9 is a pretty big behavior change if you are paying attention to the query string during POSTs. Maybe http://bugs.python.org/issue1817 gives you the information you want? Gary ___ 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] zc.buildout, substitution and templating
Shameless plug: try z3c.recipe.filetemplate.
http://pypi.python.org/pypi/z3c.recipe.filetemplate
. Sounds like it does what you want out of the box.
Gary
On Aug 27, 2009, at 9:14 AM, Encolpe Degoute wrote:
> Hello,
>
> These last days I was using collective.recipe.template and
> gocept.recipe.env.
>
> The second one just update options with os.environ.
> Unix shell having their own substitution methods then '${' appearing
> in
> the .installed.cfg. It just blows if you try to rerun 'bin/buildout.
>
> As zc.buildout is using something near string.template I patched
> gocept.recipe.env to replace '$' by '$$' and
> collective.recipe.template
> to replace '$$' by '$'.
> As _sub method in builout just split text around '$$' and join it
> again
> with '$$' we need to make the replacement with the result of this
> method.
>
> Is it the good way to deal with escaping data ?
> Or is this a bug of zc.buildout ?
>
> Regards,
> --
> Encolpe DEGOUTE
> http://encolpe.wordpress.com/
> http://encolpe.degoute.free.fr/
> Logiciels libres, hockey sur glace et autres activités cérébrales
>
> ___
> 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
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] Problem with zope.sendmail in Python >= 2.5.1
Hi all. One of the contributors to the Launchpad project has identified a problem with zope.sendmail and thread changes in Python >= 2.5.1. Here is his description: """ Description of the situation: Prior to Python 2.5.1, the atexit handlers were executed when the *main* thread exits. However,http://bugs.python.org/issue1566280 was then filed, the essence of which is that the atexit handlers could tear down cross-thread resources that were still in use by other threads. For this reason, the shutdown procedure was modified in Python 2.5.1 - now, when the main thread exits, it first makes a private call to threading._shutdown(), which waits until all non-daemon threads have exited, and *only then* proceeds to run the atexit handlers. Herein lies the problem. zope.sendmail.delivery.QueueProcessorThread attempts to use atexit to notify itself when it should shut down. However, the Python runtime >= 2.5.1 will wait for the QueueProcessorThread to exit before it calls the atexit handlers! Potential solutions: (1) To gain behaviour most similar to earlier Python versions, an evil monkeypatch into Python internals like this: http://bazaar.launchpad.net/~maxb/zope3/launchpad-3.4-py2.5/revision/9works . (2) Make the QueueProcessorThread a daemon thread. It will be terminated without notification when the interpreter exits, but the current QueueProcessorThread does not attempt to ensure its queue is completely flushed before shutdown anyway, so that should not matter. I will attach a small Python demo program useful for illustrating and exploring the issue. """ You can see the bug report, and his demo program, here: https://bugs.edge.launchpad.net/zope3/+bug/413335 I wasn't going to send this until I had investigated this myself, but I have been taking too long and thought I'd at least send this out to see if anyone has any thoughts. Otherwise, I'll look into it ASAP and report back. Thanks Gary ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Sep 11, 2009, at 9:53 AM, Benji York wrote: > On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas > wrote: >> On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: >>> 3) [no] superfluous version bumps on the trunk >> >> I don't understand this one. Could you elaborate? > > The current practice is that after doing a release you have to change > the trunk version to the next release number (a version bump). > >>> - when using a checkout as a develop egg you don't have to worry >>> about finding >>> out the exact version used on the trunk, you can always just use >>> 0. >> >> That's nice. I think I tried to use >> >> [versions] >> my-dev-package = > > Yeah, it'd be nice if buildout allowed that or some other syntax (like > "my-dev-package = *"). ...Mmm, what Marius describes works for me, I believe. I've definitely used that trick and showed it to others, at least. Maybe it worked by mistake? /me wonders if he was doing something wrong, or if he remembersbut doesn't take the time to try it again right now. But to the bigger discussion here, I'm in the "I don't like 0" camp, as I've said before. I like seeing the version number when I look at the trunk, which I do when I am doing different things than when I look at PyPI. I am skeptical of an argument that it helps prevent accidental releases. Is it not possible to make a '0' release? If it is possible, then you have to be just as careful. I think contemplating automation (e.g., release helpers that help you do the right thing, and warn you if it looks like you are doing a wrong one) is a better avenue in any case. Certainly the automation of setup.py sdist register upload is a thing of beauty in my eyes, and it could be improved. zest.releaser might be good, dunno. Also, since I'm also in the "setup.py should be able to specify minimum versions" camp (admittedly unlike others, such as Benji, to my continued surprise), I have another issue. When you use externals/ develop-eggs to organize your dependencies during interlocked jobs like my recent efforts with zc.buildout/zc.recipe.testing/ z3c.recipe.filetemplate, and you want to set a minimum dependency for one or more of the develop-eggs, this breaks if your external has a version number of 0. The '0' pattern seems like a loss for me, and at best a minimal win for those that are arguing for it. I'd prefer not to see a change, with the usual associated costs of communication and check-in police. That said, I don't this is worth a big argument, or even a big discussion (or even this email? :-). If the Zope triumverate or whatever it is these days changes the release document, so be it. :-) Gary ___ 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Sep 11, 2009, at 12:05 PM, Martijn Faassen wrote: > Hey, > > Marius Gedminas wrote: >> On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote: >>> On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas >>> wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: > 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? >>> The current practice is that after doing a release you have to >>> change >>> the trunk version to the next release number (a version bump). >> >> Right, but where does the "superfluous" come from? You'd have to >> change >> it to 0 anywa... >> >> Ah, I just realized that you do the version change on the branch/ >> tag, so >> trunk always stays at version 0. >> >> (I don't do that out of principle that tags ought not to be modified; >> and besides in other VCSes they can't be.) > > That's an interesting point. So if we were to adopt another version > control system, the 0 policy wouldn't be much of a win anymore. > Perhaps > Gary can tell us whether this would work with bzr? bzr supports a classic definition of tags--identifying a specific revision. If it's of interest or help, I include the help text for the "tag" command at the end of my message. (The way we accomplish tagging in svn is by bringing our own semantics to certain names, of course. svn doesn't help us do that inherently, it's just convention. Because that's essentially a feature of being able to name stuff, you can do similar tricks with bzr--I'd make a branch for a tag if we were were following that pattern.) Gary $ bzr help tag Purpose: Create, remove or modify a tag naming a revision. Usage: bzr tag TAG_NAME Options: --force Replace existing tags. -v, --verbose Display more information. -h, --helpShow help message. -q, --quiet Only display errors and warnings. -d ARG, --directory=ARG Branch in which to place the tag. --usage Show usage message and options. -r ARG, --revision=ARG See "help revisionspec" for details. --delete Delete this tag rather than placing it. Description: Tags give human-meaningful names to revisions. Commands that take a -r (--revision) option can be given -rtag:X, where X is any previously created tag. Tags are stored in the branch. Tags are copied from one branch to another along when you branch, push, pull or merge. It is an error to give a tag name that already exists unless you pass --force, in which case the tag is moved to point to the new revision. To rename a tag (change the name but keep it on the same revsion), run ``bzr tag new-name -r tag:old-name`` and then ``bzr tag --delete oldname``. ___ 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] where is zc.zservertracelog 1.2.0?
Hi. pypi advertises http://pypi.python.org/pypi/zc.zservertracelog/1.2.0 but there is no download to be found! :-) Could whoever made the release add the download? Thanks Gary ___ 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] where is zc.zservertracelog 1.2.0?
On Sep 11, 2009, at 4:57 PM, Alexander J Smith wrote: > On Fri, Sep 11, 2009 at 4:54 PM, Alexander J Smith > wrote: >> On Fri, Sep 11, 2009 at 4:44 PM, Marius Gedminas >> wrote: >>> On Fri, Sep 11, 2009 at 03:51:30PM -0400, Gary Poster wrote: >>>> Hi. pypi advertises http://pypi.python.org/pypi/zc.zservertracelog/1.2.0 >>>> but there is no download to be found! :-) Could whoever made the >>>> release add the download? >>> >>> Is it important that the same person do it? In theory, since svn >>> has >>> tags for all releases, anybody could check out the right tag and do >>> >>> python setup.py sdist upload I believe you need to have PyPI privileges for that distribution in order to upload--an elite set of alexsmith, J1m, benji, achapman. :-) >>> >> >> Sorry, my mistake! I'm fixing this right away. >> >> >> -- >> Alex Smith >> Software Engineer >> Zope Corporation >> > > Fixed :) Thank you very much Alex! :-) Gary ___ 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] Subversion externals versus mirroring
On Sep 11, 2009, at 9:34 AM, Chris Withers wrote: > Martijn Faassen wrote: >> Christian Theune wrote: >> [snip] >>> Same here. We also ended up in many deadlock situations having to >>> sacrifice chickens for SVN to resume operations. That's why we >>> started >>> investigating alternatives which are better at branching and >>> merging. >> >> Please keep up posted. We have a standing offer from Canonical to >> host >> our stuff in bzr. The move of the Python core developers to >> mercurial is >> also interesting. > > I've been impressed with TortoiseHg so far (after a few initial > hiccups) > and it looks like they're aiming to be cross platform with it, which > is > a pretty big draw, although the MacOS port isn't ready yet... > > How has TortoiseBzr progressed? My understanding is that TortoiseBzr has largely withered on the vine in favor of a new effort: BzrExplorer, based on Qt, and running on Linux/Windows/Mac. http://bazaar-vcs.org/BzrExplorer That page has links to lots of information. The very little information I have is based on those pages, so, for now, please look there for now rather than asking me anything. Once Bzr 2.0 comes out (in less than a month AIUI), I'll at least send out a link to it and point out some changes made that specifically address concerns raised by Zope Foundation members when I raised Launchpad's/Canonical's offer before. If there are any questions then, I'll be happy to try to get answers. Gary ___ 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] Problem with zope.sendmail in Python >= 2.5.1
On Sep 3, 2009, at 10:53 PM, Chris McDonough wrote: > FWIW, we forked zope.sendmail a while back (with the intent of > eventually merging these changes back upstream) as > "repoze.sendmail". It does not use any thread to do queue > processing. Instead, a separate process can be run to handle queue > processing. > > This is being actively maintained. > > http://repoze.org/viewcvs/repoze.sendmail/trunk/README.txt?rev=3688&view=markup Thank you Chris. On the face of it, it sounds like it could be merged in with zope.sendmail very easily, if you have the same interfaces. The zope.sendmail package already advertises the ability to use an external process for processing queued mail, but that appears to be an aspect of the design and the interfaces rather than in the implementation. For this particular problem I faced, though, sticking with threads was easier for now. Gary ___ 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] Subversion externals versus mirroring
On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote: > > In my experience distributed SCMs add bottlenecks to development > that we > currently do not have in the Zope community: with both our shared svn > repository and distributed SCMs everyone can branch everything, but > with > distributed SCMs you have to ask a maintainer to merge any changes, > something everyone can do directly right now. FWIW, this is some variable degree of wrong. 1) "Everyone" cannot merge changes right now: only developers that have commit privileges can do that. That's what you meant, I expect. 2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team. Generally, I'd be surprised to learn that Bzr/Launchpad were alone in supporting this, but they are the only ones I can vouch for. For instance, I'm almost positive that github also allows you to have multiple committers to a single branch, though I don't remember the mechanism. Gary ___ 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] Subversion externals versus mirroring
On Sep 15, 2009, at 7:59 AM, Wichert Akkerman wrote: > On 9/15/09 13:56 , Gary Poster wrote: >> > >> 2) Our current arrangement, as well as many others, can be >> accomplished >> with a DVCS. Launchpad + Bzr definitely support this. You would >> have a >> Launchpad team of committers, with managed membership; and have the >> official branches owned and controlled by this team. > > Indeed, but most people do not do that. With our current setup once > you get commit privileges you immediately have access to an entire > world of things. With DVCS hosting systems that people use you have > would have to request access for every single package. That is > cumbersome and adds a lot of delay so people don't do that and fork > instead. The end result is a lot more forks, half of which will > probably never be merged back or seen by others. Perhaps that is the way other systems work; again, I can only vouch for Bzr/Launchpad, and your description is incorrect for us. With Bzr/Launchpad, a single time for each project, you would designate an appropriate committer team as having commit privileges for that project. Then, for each person that should be able to commit to all of the projects, you add them to that team. This is how we have our open-source Zope-friendly lazr.* packages set up. We have a single team for committers, which has privileges for all of our lazr.* packages. When a new person should be able to commit to all of the packages in the lazr.* effort, we just add them to that team. See, for instance, the trunk of lazr.delegates: https://code.launchpad.net/~lazr-developers/lazr.delegates/trunk . You simply need to be added to lazr-developers ( https://launchpad.net/~lazr-developers ) in order to commit to this and any of the other similarly- configured lazr.* projects. Gary ___ 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] ZTK test failures - zope.testing
On Sep 15, 2009, at 6:33 PM, Sidnei da Silva wrote: > Hi Hanno, > > On Tue, Sep 15, 2009 at 6:42 PM, Hanno Schlichting > wrote: >> We are down to zero-build problems for the ZTK and just one test >> failure. This is in zope.testing in testrunner-layers-buff.txt. > > That smells like something Gary has touched recently. Meh, yes indeed--for all but one failure (see below). The Ubuntu one should be easy to fix. The Windows ones may be tied up with \n \r fun. It should be trivial too, though I'll need to get a Windows VM back up--or request aid from Sidnei. ;-) I'll address these issues tomorrow. However, there is a Windows failure that I don't think is on my plate, and I'd appreciate someone else looking at it: zope.testing-3.8.2- py2.4.egg\zope\testing\testrunner\testrunner-test-selection.txt, line 166, in testrunner-test-selection.txt . That's the very last one on http://dev.thehealthagency.com/buildbot/builders/ztk-win-py2.4%20slave-win-py2.4/builds/21/steps/test/logs/stdio . If someone else can address that last one, and I address the rest, we can have a new release. Gary ___ 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] Proposal: Determining packages which are in the ZTK
On Sep 18, 2009, at 11:53 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This is from a note I sent yesterday to the ZTK steering group > (Martijn, > Christian, Jim, Stephan), proposing criteria for removing packages > from > the ZTK. Martijn has already updated the docs to reflect some of the > criteria: I figured I would throw the rest out for discussion: > > - - If a ZTK package isn't used by at least Zope2 and Grok, it > probably > isn't getting the love needed to stay at an appropriate quality level > to meet the ZTK goals. Given that the Zope2 developers have as an > explicit goal removing dependencies on *any* zope.app.* package, I > obviously believe that such packages should not be part of the ZTK. > > - - Any package which doesn't have real narrative documentation > checked > into its 'docs' subdirectory, or a commitment from a maintainer > to create such docs, should be on probation. > > - - Any package which depends on a zope.* package which is *not* part > of the ZTK should itself be removed from the ZTK. > > - - As a corollary, any package which depends on any other > "probationary" > package is automatically probationary itself. > > - - (A little more speculative) Any package which doesn't have one or > more clearly-identified maintainers should be probationary. > > - - Packages which remain in the probationary status for a given > period > (three months? six?) should be removed from the ZTK. > > The overall goal here is to keep the ZTK as coherent as possible, and > avoid "bitrot" by focusing on the packages which are in active use by > more than one project. Sounds interesting. Do you happen to have a list of packages that would be affected by these rules? Gary ___ 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] ZTK test failures - zope.testing
Hi. I didn't get it done on the 17th, but I did just make a release with the necessary fixes (or, the tests pass for me on Windows and Ubuntu, at least; they already were passing for me on Ubuntu, but I made the pertinent test somewhat less fragile). Gary On Sep 16, 2009, at 3:39 AM, Hanno Schlichting wrote: > On Wed, Sep 16, 2009 at 3:53 AM, Gary Poster > wrote: >> The Ubuntu one should be easy to fix. >> >> The Windows ones may be tied up with \n \r fun. It should be >> trivial too, >> though I'll need to get a Windows VM back up--or request aid from >> Sidnei. >> ;-) >> >> I'll address these issues tomorrow. > > Awesome. > >> However, there is a Windows failure that I don't think is on my >> plate, and >> I'd appreciate someone else looking at it: >> zope.testing-3.8.2-py2.4.egg\zope\testing\testrunner\testrunner- >> test-selection.txt, >> line 166, in testrunner-test-selection.txt . That's the very last >> one on >> http://dev.thehealthagency.com/buildbot/builders/ztk-win-py2.4%20slave-win-py2.4/builds/21/steps/test/logs/stdio >> >> . > > You refer to the "ImportError: No module named c:.documents"? I hope I > fixed that one already, but didn't make a new release yet. That was > the typical "path with a space in it" problem, as found in > http://svn.zope.org/zope.testing/trunk/?rev=104110&view=rev > > Thanks, > 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 )
[Zope-dev] Bazaar 2.0 (was Re: Subversion externals versus mirroring)
On Sep 14, 2009, at 2:02 PM, Gary Poster wrote: > Once Bzr 2.0 comes out (in less than a month AIUI), I'll at least > send out a link to it and point out some changes made that > specifically address concerns raised by Zope Foundation members when > I raised Launchpad's/Canonical's offer before. If there are any > questions then, I'll be happy to try to get answers. Bzr 2.0 is out. I personally find the speed improvements very impressive. The new repository format is much smaller, and intended to be stable, and the project has a adopted a six-month maintenance release approach. It has a new website. http://bazaar-vcs.org/en/ It has a new front-end for Gnome/KDE/Mac OS X/Win. The screenshots look impressive to me, which is all I can vouch for. http://doc.bazaar-vcs.org/explorer/en/visual-tour-windows.html Cross-platform end of line conversion is implemented, which was one of the concerns raised earlier. http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line-conversion I don't remember if anyone brought up the lack of a parallel to svn externals. That functionality (called nested trees for bzr) is not implemented yet. It is important to Launchpad's usage of the tool, though, so it is in the six-month pipeline, as I understand it. I'm happy to try to field any questions if anyone has any. Gary ___ 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] A note on the PyCon Program committee.
On Nov 3, 2009, at 4:48 PM, Chris McDonough wrote: > Gary Poster wrote: ... >> It is an advocacy piece only in the sense that we are saying that, >> by-and-large, we like what the packages give us, but it is more >> challenging than that. It's an interesting pairing to Jeff Shell's >> invited talk, which appears to cover some of the same ground from >> more of an advocacy/tutorial perspective. I was honestly a bit >> surprised that mine was accepted when Jeff's was already scheduled, >> but maybe mine is "the dark side" version of his talk. :-) > > It's Jeff Rush.. Bah, I knew that. Thanks for the correction. Sorry, Jeffs. Gary ___ 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] A note on the PyCon Program committee.
I had a "rethinking interfaces" talk accepted. It's about the positives and negatives of zope.interface and zope.component, driven primarily from the perspective and experience of the Launchpad team, and myself in particular; and about changes that might be made or differences we are interested in. It is an advocacy piece only in the sense that we are saying that, by- and-large, we like what the packages give us, but it is more challenging than that. It's an interesting pairing to Jeff Shell's invited talk, which appears to cover some of the same ground from more of an advocacy/tutorial perspective. I was honestly a bit surprised that mine was accepted when Jeff's was already scheduled, but maybe mine is "the dark side" version of his talk. :-) Gary On Nov 3, 2009, at 2:13 PM, Chris McDonough wrote: > So were any Zope talks/tutorials accepted? > > FWIW, Tres had a BFG talk accepted, and Carlos had a BFG talk and a > BFG > tutorial accepted. I proposed a talk about profiling that didn't > make it. > > The TG guys had one talk accepted. > > Not sure about Pylons. > > I assume Django had a bunch, but I don't know for sure. > > - C > > > Martijn Faassen wrote: >> Chris McDonough wrote: >> [snip] >>> Another way to avoid this in the future besides joining the >>> committee would be >>> for notable members of the Zope community to reach out on a >>> regular (daily) >>> basis to other Python-using communities. Offer them well- >>> documented software, >>> visit their sprints and conferences, try their alphas, join their >>> IRC channels, >>> participate in their maillists and so on. It's harder to do >>> intercommunity >>> politics daily in this way as opposed to "facing off" yearly, but >>> it will have >>> a higher, more lasting payoff. >> >> I'm very much in agreement on this. Blogging is another way to reach >> out. Reach out and interact. >> >> It's indeed hard work to do this right. I am sitting on a few >> pieces of >> software that are either interesting to non-Zope people or in fact >> directly usable, but I haven't had the time yet to blog about them. I >> intend to start blogging on a more regular basis again soon. >> >>> It's "who you know", not "what you know" unfortunately, even in >>> open source, as >>> much as we like to believe in meritocracy. >> >> That's true too. I'm a natural noise-maker, and I discovered that >> while >> as a result of this I embarrass myself in public on a regular >> basis, it >> also means a lot of people know who I am. That's a good thing. >> >> 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 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 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] A note on the PyCon Program committee.
On Nov 3, 2009, at 3:28 PM, Lennart Regebro wrote: > 2009/11/3 Gary Poster : >> I had a "rethinking interfaces" talk accepted. It's about the >> positives and negatives of zope.interface and zope.component, driven >> primarily from the perspective and experience of the Launchpad team, >> and myself in particular; and about changes that might be made or >> differences we are interested in. >> >> It is an advocacy piece only in the sense that we are saying that, >> by- >> and-large, we like what the packages give us, but it is more >> challenging than that. It's an interesting pairing to Jeff Shell's >> invited talk, which appears to cover some of the same ground from >> more >> of an advocacy/tutorial perspective. I was honestly a bit surprised >> that mine was accepted when Jeff's was already scheduled, but maybe >> mine is "the dark side" version of his talk. :-) > > Well, if you cover the good and bad sides, as your great OSCON talk > did, but then also proposes what can be done about the bad sides, your > talk would be of narrower interest, but also more important. :-) Cool, I'll aim for that. :-) > I'm really sorry I can't go to PyCon this year, the talks are going to > be awesome. Hopefully I can see the talk online at some stage. :) I'm sorry you won't be there too, but thank you! Gary ___ 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] zc.relationship - can't pickle module objects
Hi Patrick. I do not have privileges for this egg, and am not responsible for it. I'm hopeful someone can help you with it, though. Gary On Nov 9, 2009, at 5:55 AM, Patrick Gerken wrote: > Hi, > > while this "can't pickle" issue is fixed in zc.relationship, the > latest packaged egg > of plone.relations still depends on zc.relationship<1.1. Thus this > issue persists if one uses the latest plone.relations egg. > This has been fixed on in svn, could somebody with permissions > create a new egg? > > Best regards, > > Patrick > > > > On Tue, Mar 17, 2009 at 16:00, Gary Poster > wrote: >> >> On Mar 16, 2009, at 10:55 PM, Martin Aspeli wrote: >> >>> Gary Poster wrote: >>> >>>> Yes, +1. Thank you. I was about to write to your other message >>>> that >>>> this was quite possibly the only 3.8 dependency. >>> >>> Cool. Committed. >>> >>>>> If we do that, then we can let plone.relations depend on >>>>> zc.relationship >>>>> 1.1.1 explicitly and have support for both ZODB versions, which >>>>> would be >>>>> nice. >>>> >>>> Sounds great. Would you like access to the PyPI zc.relationship >>>> record so you can upload the new version? If so, are you "optilude" >>>> there? >>> >>> That'd be great, yeah. Or else, if you want to tag a release from >>> the >>> 1.1 branch, that should be safe (and even less work for me :-) >> >> OK. I changed setup to fix the tests with the most recent packages, >> made a tag and release, and gave you access to the PyPI package just >> in case. >> >> Gary >> >> ___ >> 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 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] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 10:41 AM, Martijn Faassen wrote: ... > Thoughts? FWIW, this mirrors some of the thoughts I've had, after a lot of discussions with Launchpad/Canonical engineers about the pros and cons of the Zope interface and component code. My OSCON presentation touched on some of these discussions, observations and ideas. Ideas on addressing the problems in the feedback are the focus of my upcoming PyCon presentation. I'm in the middle of an experiment to modify the code without backwards compatibility concerns, to see where it takes me. Obviously, there's an extremely high hurdle for backwards incompatibility, but it was the experiment I wanted to pursue, and one that (obviously) I felt had merit. My intent is to show these at PyCon and start a discussion about the value of the changes, what could be done without breaking backwards compatibility, what could be done with minimal backwards compatibility breakage, and if anything I discovered merits more significant breakage. I'd prefer to think about these myself for a while, and continue to experiment. I've already digested a lot of feedback, from the interviews at Launchpad and Canonical, from past mailing list discussions, from documents like BFG's design defence (http://docs.repoze.org/bfg/1.1/designdefense.html), and from personal discussions. Most people have heard some variation of the (perceived/real) problems before; I'm not ready to settle on my preferred solutions myself. I'm seeing how everything fits together, and it's a big puzzle to assemble. My experiments don't need to hold anyone else up, of course, but I do have a concrete deadline to deliver something. :-) I'll share once I feel that I am reasonably happy with my choices, which may or may not be significantly before PyCon. If other folks want to run on without me, I can at least point to the slides for the OSCON talk I gave with the Canonical/Launchpad feedback if you are interested. Gary ___ 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] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: > Martijn Faassen wrote: > >> Adapter: >> >> IFoo(x) > > [...] > >> Multiadapter: >> >> IFoo.multi(x, y) > > [...] > >> Utility: >> >> IFoo.utility() >> >> [or possibly IFoo() instead?] > > What about a simple and consistent API for all components including > utilities, adapters and multiadapters: > > IFoo() > IFoo(x) > IFoo(x, y) > > I seem to remember there had been some discussion at some point about > dropping or at least loosening the distinction between utilities and > adapters anyway, so this would be the opportunity to do so at the API > level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. Gary ___ 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] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:34 AM, Thomas Lotze wrote: > Gary Poster wrote: > >> >> On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: >> >>> What about a simple and consistent API for all components including >>> utilities, adapters and multiadapters: >>> >>> IFoo() >>> IFoo(x) >>> IFoo(x, y) >>> >>> I seem to remember there had been some discussion at some point about >>> dropping or at least loosening the distinction between utilities and >>> adapters anyway, so this would be the opportunity to do so at the API >>> level. >> >> That was discussed and rejected near the very beginning of the Z3 >> effort, in my memory. > > OK. If that was a hard and fast decision, I'll not argue further. FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. Gary ___ 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] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:54 AM, Chris McDonough wrote: > Gary Poster wrote: >> FWIW, I'm saying that utilities and adapters are different. I share >> your/Martijn's/other people's general thoughts about merging adapters and >> multiadapters in the interface __call__ syntax. > > There might should be more obvious APIs for just *retrieving* an adapter > based on a set of interfaces; it's useful to be able to retrieve an adapter > without invoking it. Currently this is possible via > registry.adapters.loookup, which is fine. > > And I know it's heresy, but sometimes I register something as an "adapter" > that is not callable with the number of arguments I'm adapting it with. > Sometimes its convenient to register something that gets adapted using a > number of arguments that doesn't match the adaptation arguments. > > If some set of ZCA APIs made it the responsibility of the *caller* to invoke > the adapter with arguments would go a long way between normalizing the > difference between utilities and adapters (because they would essentially > then be the same thing). Yeah, this is one of my goals too. Gary ___ 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] split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs)
On Nov 25, 2009, at 5:08 PM, Chris McDonough wrote: > Chris McDonough wrote: >>> If some set of ZCA APIs made it the responsibility of the *caller* to >>> invoke the adapter with arguments would go a long way between normalizing >>> the difference between utilities and adapters (because they would >>> essentially then be the same thing). > > The very core mechanics of how a component registry behaves resides almost > entirely in the zope.component.registry module. > > It would be useful to split these core mechanics into a separate package. > Here's why: > > - The zope.component module carries along an expectation of a particular > global > API. This global API is not required to use the mechanics of the underlying > registry machinery. > > - The zope.component package has a number of features that are irrelevant > to the operation of the core registry itself, such as persistence and > security. > > - The registry itself is useful outside the context of the zope.component API > package; the API is essentially just "candy" on top of the registry itself. > > I have created such a package at > http://svn.zope.org/Sandbox/chrism/zope.registry > > It contains an implementation of the registry and the tests for the registry > object. It depends on zope.interface and zope.event. I'd like to actually > remove the zope.event dependency and release a newer version of zope.event > that uses a global inside zope.registry as the list of registered object > (reverse the dependency). > > After that's done, I'd suggest we make zope.component depend on zope.registry. > > At this point, people can innovate with their own APIs to the registry object > as necessary; they needn't carry along the baggage of the expecation of the > older zope.component API working in their app. > > Thoughts? FWIW, it's not of a lot of interest to me. I'm interested in changing things at a lower level. However that works, if I manage to build zope.component backwards compatibility as an add-on then I'll have to worry about all of the bits in zope.component, not just this. Gary ___ 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] improving the utility and adapter lookup APIs
On Nov 30, 2009, at 4:05 AM, Brian Sutherland wrote: > On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote: >> On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver wrote: >>> Hmm, I may be missing something here, but if Foo implements IFoo, then >>> the getAdapter lookup for it will short circuit, leading you into >>> infinite recursion. Except that it doesn't: >> >> [snip example] >> >>> which strikes me as wildly disjoint: the IFoo behavior is "expected" >>> (short-circuit the lookup if the object already provides the interface), >>> while the getAdapter behavior is a puzzlement. >> >> This has been mentioned numerous times as one of those odd and >> unexpected differences between the IFoo vs. get/queryAdapter semantic. >> IIRC the only use-case I ever heard of for the getAdapter semantic, >> was the possibility to override the behavior promised by the interface >> with a different adapter without touching the class that implements >> the interface directly. >> >> I think changing this falls into the category of: Small backwards >> incompatibly that seem worthwhile to make the behavior consistent and >> expected. > > I do agree that this behaviour is inconsistent with the common idea of > adapters in the ZCA. So it doesn't have to be in the "main API" to the > ZCA, i.e. the one people most heavily and frequently use. > > But, I'll argue that it should be still possible if you are willing to > go outside the main API. > > My particular usecase is Location objects implementing IPublishTraverse > without depending on the default traversal adapter: > >class FakeContainerOfSomeKind(Location): > >implements(IPublishTraverse) > >def publishTraverse(self, request, name): >if name.isdigit() and do_i_contain(name): >return get_the_object_i_contain(name) ># fallback to default traversal adapter without depending on it >traverser = getMultiAdapter((self, request), IPublishTraverse) >return traverser.publishTraverse(request, name) > > I wouldn't know how to implement the above code without either depending > directly on the default traversal adapter or making an > IDefaultPublishTraverse marker interface. Neither of those, in my > opinion, is as elegant as the above. I'd argue what you have is pretty obscure though--that is, reading your code example, I'd have to stare at it a while to figure out why it works, and I know the component machinery pretty well. The IDefaultPublishTraverse thing would be inelegant but much more readable. I'd want to think about this class of use cases harder if it were regarded as an important one. I am myself somewhat interested in being able to turn off the short-circuit behavior explicitly if desired. That said, for "multiadapters" involving more than one required object, IMO the short-circuit behavior should never be invoked. It is not clear that the first object is the one that should be checked for already providing the desired interface. Therefore, in this particular usage, ``IPublishTraverse(self, request)`` would do what you want. Gary ___ 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] implementing zope.component 4.0
On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: > Hi there, > > Introduction > > > So now that we've had some discussion and to exit the "bikeshed" phase, Wow. That's abrupt, for something at the root of the entire stack. I don't think long emails are very effective, but I'm not sure how else to reply to your long email. > let's see about getting some volunteers to work on this. > > The goal here is to make interfaces disappear into the language as much > as possible. This means that I'll ignore backwards compatibility while > sketching out the "ideal semantics" below - I have the impression we can > get consensus on the following behavior: > > Simple adaptation: > > IFoo(adapted) > > Named adaptation: > > IFoo(adapted, name="foo") > > Adaptation with a default > > IFoo(adapted, default=bar) > > Multi-adaptation: > > IFoo(one, two) > > Named multi adaptation: > > IFoo(one, two, name="foo") > > Multi-adaptation with a default: > > IFoo(one, two, default=bar) I am in favor of the above, given a backwards compatibility story that makes existing packages work. > > Utility lookup: > > IFoo() > > Named utility lookup: > > IFoo(name="foo") > > Utility lookup with a default: > > IFoo(default=bar) I disagree with this. More below. > Where "name" and "default" can be combined. The name and default keyword > parameters have to be used explicitly - *args is interpreted as what to > adapt only. Any other keyword parameters should be rejected. > > Utility lookups versus adapter lookups > -- > > There was some discussion on whether utility lookups are really > something fundamentally different than adaptation as adaptation > *creates* a new instance while utility lookup uses a registered > instance. I think the essential part here is however: "give me an > instance that implements IFoo", and utility lookup fits there. We could > even envision a way to create utilities that *does* instantiate them on > the fly - it shouldn't affect the semantics for the user of the utility. As above, I disagree. As a matter of mechanics, when you register something we call an adapter, it is a callable that takes one or more arguments. If we were going to follow the pattern that Marius laid out to establish what happens when, then we have this, roughly: register callable that takes two arguments: IFoo(bar, baz) register callable that takes one argument: IFoo(bar) register callable that takes no arguments: IFoo() If instead we have the last step as what is proposed here register non-callable IFoo() then I think that breaks an important pattern for usage understandability. That is, IFoo() can have a semantic if that is valuable, but it is not the same as registering and getting non-called singletons. Two by-the-ways: 1) The term "adapter" is a barrier to understandability, in my interviews. This is particularly the case when people are introduced to the idea of "multiadapter" and "supscription adapter". In what ways are these anything like a type cast? IMO, they are not. Our usage of adapter is as a factory. Yes, it can be used in other ways--so can a Python class--but that is the essence of how our community uses this technology. Calling all these ideas "adapters" accomplishes nothing. Explaining all of the ideas as "a factory to produce an object that provides the interface" cleanly describes our usage, and both "adapters" and "multiadapters". (To be complete, I am in favor of ditching "subscription adapters" in favor of other mechanisms related to named singleton lookups.) One reason I like the syntax proposals for the adapter change is that they treat the interfaces as pluggable factories. This is apt. 2) The term "utility" is another barrier to understandability. They are singletons. Explaining them as such is a "well, why didn't you say so" experience. Therefore, I am in favor of removing the necessity to use the word utility. That said, they are not factories. They should not be mixed with the two. My preference for future changes is to have an API using the ``singleton`` name. Moreover, I think that some of the use cases that Marius referred to for underpowered "utilities" coud be remedied by having a utility/singleton lookup that allowed looking up by required values like the adapter/factory lookup. > Features off the table for now > --- > > Saying an interface is implemented by a class (Python 2.6 and up) with a > decorator we'll leave out of the discussion for now. > > It would also be come up with an improved API to look up the adapter > *before* it is called, but I'd also like to take this off the table for > this discussion. It seems to me that this, along with the documentation call that Chris gave, is a much more valuable immediate effort. One of the biggest complaints I heard was with debugging. I've spent some thought
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 11:51 AM, Chris McDonough wrote: > Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Gary Poster wrote: >>> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: >> >>>> Utility lookups versus adapter lookups >>>> -- >>>> >>>> There was some discussion on whether utility lookups are really >>>> something fundamentally different than adaptation as adaptation >>>> *creates* a new instance while utility lookup uses a registered >>>> instance. I think the essential part here is however: "give me an >>>> instance that implements IFoo", and utility lookup fits there. We could >>>> even envision a way to create utilities that *does* instantiate them on >>>> the fly - it shouldn't affect the semantics for the user of the utility. >>> As above, I disagree. >> >> The root of the disagreement here is that you seem to want the *caller* >> to care about something which is important only to the person who >> *registers* the thing being looked up. From the caller's perspective, >> the call site needs an object implementing IFoo, looked up using some >> number N of context arguments, where N could be 0 (no context required >> to find the object). The fact that, under the hood, an adapter lookup >> happens to call a factory, passing the context args, is not relevant *to >> the caller*. > > I understand that the idea explained above is conceptually integral to a lot > of > people, and basically unquestionable. But as devil's advocate sort of thing > can we put this traditional worldview aside for a minute, and just sort of > take this from ground zero? > > In "normal Python", callers often do need to understand whether the function > they're calling is a factory which constructs a new object, or a function > which > returns a "global", because the caller needs to know what the impact of > mutating the result is. > > We call non-factories utilities and we call factories adapters. So the > caller > *already* needs to make a distinction between the two. Yes. Gary ___ 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] implementing zope.component 4.0
On Nov 30, 2009, at 1:51 PM, Chris McDonough wrote:
> Shane Hathaway wrote:
...a good general argument, that Chris seemed to agree with and expand upon,
and that has some merit to me.
>
>> What do you think?
>
> + 1 with the following caveat:
>
> I think that method name should probably be "adapt"; "lookup" should maybe
> be
> a separate method reserved for passing bare interfaces rather than objects
> which implement interfaces, e.g:
...
1) I very much like the idea of some helpers hanging around. However, my
current belief is that the factory "methods" ought to be callable objects that
allow introspection of the underlying registry. That's where the "lookup"
style behavior belongs, IMO, as well as other helpers. See below for examples.
2) As argued before, I think that "adapt" is an ok name for a single object,
but becomes a bad name once you have "multiadapters" in the mix. I would
prefer one of the options Matthias Lehmann proposed ("new" for instance).
3) I also think that "utility" is a bad name. Is "singleton" two letters too
long? If it is, I mind "utility" less than I mind "adapter".
IFoo.new(a, b) # finds and returns result of call
IFoo.new.lookup(IA, IB) # finds and returns callable
IFoo.new.find(IA, IB) # get all registration information
IFoo.new.find_stack(IA, IB) # get an iterable of the stack all registration
information for each registration for those two interfaces
IFoo.singleton() # finds and returns item
IFoo.singleton(name='baz') # finds and returns item
IFoo.singleton.lookup(name='baz') # same result in this case
IFoo.singleton.find(name='baz') # get all registration information
Side, but related point:
I wonder if there is value in the ability to spell
IFoo.singleton(a) # where "a" is a required object to the registration. This
would make utility registrations more powerful in a way that some people seem
to have been missing. It also makes things parallel with creation.
Gary
___
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] implementing zope.component 4.0
On Nov 30, 2009, at 11:47 AM, Martijn Faassen wrote: > Hey, > > Gary Poster wrote: >> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: ...snipping here and elsewhere without further warning... >>> Utility lookup: >>> >>> IFoo() >>> >>> Named utility lookup: >>> >>> IFoo(name="foo") >>> >>> Utility lookup with a default: >>> >>> IFoo(default=bar) >> >> I disagree with this. More below. > > [snip] >> As a matter of mechanics, when you register something we call an >> adapter, it is a callable that takes one or more arguments. If we >> were going to follow the pattern that Marius laid out to establish >> what happens when, then we have this, roughly: >> >> register callable that takes two arguments: IFoo(bar, baz) >> >> register callable that takes one argument: IFoo(bar) >> >> register callable that takes no arguments: IFoo() >> >> If instead we have the last step as what is proposed here >> >> register non-callable IFoo() >> >> then I think that breaks an important pattern for usage >> understandability. > > I still don't see why that isn't an implementation detail. How we get an > IFoo doesn't concern us when we're calling it, as long as we get an > IFoo? Even with adaptation a singleton could be returned; it's just the > implementation of such would be different. The people I know are involved in both registration and usage of these things. > If we take Marius' pattern, registring a singleton directly would simply > be a shortcut API for registring a factory for utilities. (Utility > factories would make it easier to implement local utilities that aren't > ZODB-backed...) Make those factories that do not take arguments. That's the use case for IFoo(). > >> That is, IFoo() can have a semantic if that is valuable, but it is >> not the same as registering and getting non-called singletons. > > What is this valuable semantic? Marius said he has had a use case. It sounds like you gave one above. > > [snip] >> (To be complete, I am in favor of ditching "subscription adapters" in >> favor of other mechanisms related to named singleton lookups.) > > I really need to think through subscription adapters; I haven't done any > analysis about those. > >> 2) The term "utility" is another barrier to understandability. They >> are singletons. Explaining them as such is a "well, why didn't you >> say so" experience. > > Another way to explain utilities is that getting a utility is a lot like > importing something in Python, except that what is imported is pluggable > and the required interface is specified explicitly. > >> Therefore, I am in favor of removing the necessity to use the word >> utility. That said, they are not factories. They should not be >> mixed with the two. My preference for future changes is to have an >> API using the ``singleton`` name. > > "import by interface" to me sounds like it'd clarify matters for more > Python programmers. Singleton has all kinds of design pattern > connotations that don't really apply here. > >> Moreover, I think that some of the >> use cases that Marius referred to for underpowered "utilities" coud >> be remedied by having a utility/singleton lookup that allowed looking >> up by required values like the adapter/factory lookup. > > I don't understand. Could you rephrase? Right now you can only look up a utility with a desired output, and optional name. Is it useful to also be able to pass in a context of objects for the lookup (the "required" values in the underlying implementation)? > >>> Features off the table for now --- >>> >>> Saying an interface is implemented by a class (Python 2.6 and up) >>> with a decorator we'll leave out of the discussion for now. >>> >>> It would also be come up with an improved API to look up the >>> adapter *before* it is called, but I'd also like to take this off >>> the table for this discussion. >> >> It seems to me that this, along with the documentation call that >> Chris gave, is a much more valuable immediate effort. One of the >> biggest complaints I heard was with debugging. I've spent some >> thought on the debugging story, and have some APIs sketched out in my >> experiments--it was one of the first things I worked on. To do it >> cleanly (the way I envision) would require some work, but a first cut >> wouldn't be too bad. > > Hm, I disagree about what's more valuable. Sure; we have different perspectives on who we are aiming for. You have said you are not aiming for new/non-expert users, at least in this round. In contrast, they are my primary clients. Gary ___ 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] implementing zope.component 4.0
On Nov 30, 2009, at 3:49 PM, Charlie Clark wrote:
> Am 30.11.2009, 20:24 Uhr, schrieb Gary Poster :
>
>> 1) I very much like the idea of some helpers hanging around. However,
>> my current belief is that the factory "methods" ought to be callable
>> objects that allow introspection of the underlying registry. That's
>> where the "lookup" style behavior belongs, IMO, as well as other
>> helpers. See below for examples.
>
>> 2) As argued before, I think that "adapt" is an ok name for a single
>> object, but becomes a bad name once you have "multiadapters" in the
>> mix. I would prefer one of the options Matthias Lehmann proposed ("new"
>> for instance).
>
> I have no great problem with multiadapters as long as the analogy is clear
> enough - "this adapter takes two sources..."
Well, my first issue is that the "adapter" word is unnecessary by my
definitions.
Then to the multiadapter concern I raised, all my real-world examples of
adapters are to adapt one object so it can be used in a certain way (to
integrate with another kind of object). Power adapters, for instance, adapt a
plug (required interface) so it can plugged in to the wall (output interface).
Is there a common real-world example of this for "multiadapters"?
>> 3) I also think that "utility" is a bad name. Is "singleton" two
>> letters too long? If it is, I mind "utility" less than I mind "adapter".
>
> I don't understand this. For me a singletons is (sic) a highly specific
> programming term whereas adapters and utilities, especially in the way we
> refer to them, are not so domain specific.
Turned around, people know the term "singleton" and they do not know the terms
"adapters" and "utilities". "singletons" describe the huge majority of how we
use these things. It's something less to explain. Making comprehension
quicker is very valuable to me.
Put yet another way, how are 99+% of our "utility" usages not singletons? If
that's the case, what's the value of having to explain what a utility is? How
do you reply when the people you support say, "oh, so this is just a singleton,
right?"
That said, and to repeat, I mind "adapter" more than "utility."
>> IFoo.new(a, b) # finds and returns result of call
>> IFoo.new.lookup(IA, IB) # finds and returns callable
>> IFoo.new.find(IA, IB) # get all registration information
>> IFoo.new.find_stack(IA, IB) # get an iterable of the stack all
>> registration information for each registration for those two interfaces
>> IFoo.singleton() # finds and returns item
>> IFoo.singleton(name='baz') # finds and returns item
>> IFoo.singleton.lookup(name='baz') # same result in this case
>> IFoo.singleton.find(name='baz') # get all registration information
>
> Interestingly this is starting to look too verbose and java like to me but
> I'm also not happy with the use of "new" or "singleton". "find" might be
> an idea if it could use introspection to gives clues as to what I might
> actually want to do with my IFoo implementers. Can you give some sample
> responses?
The majority of those were advanced, or debug usage. That's the kind of thing
that Chris was talking about, at least in my estimation if not in his :-) .
Here's basic usage. I'll use "utility" since I'm getting more pushback on that
one. :-)
``IFoo.new(a, b)`` is equivalent to getMultiAdapter((a, b), IFoo)
``IFoo.utility()`` gives you the singleton registered for IFoo.
That's the basic idea. It's basically what Shane proposed, with the "adapter"
-> "new" thing (and my squelching of "utility" -> "singleton").
What if you want to determine how you got the result that you got? You need
some additional methods. My proposal was that you put those methods off of
``.new`` and ``.utility``. You could also make other methods (or objects) off
the interface.
In my experiments, I have the following debug and utility/advanced methods.
You would typically only look at these if you were trying to figure out what
was going on, or if you were doing something tricky.
.lookup (what Chris proposed)
.lookup_all (also based on the registry call of the same method)
.find (get registration information--that is, value, required, provided,
name--for the same input as lookup)
.find_all (get registration information dictionary for the same input as
lookup_all)
.find_stack (returns an iterable of registrations, beginning with the one that
would have been chosen, and followin
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 4:13 PM, Zvezdan Petkovic wrote: > > On Nov 30, 2009, at 4:05 PM, Zvezdan Petkovic wrote: > >> On Nov 30, 2009, at 2:24 PM, Gary Poster wrote: >>> 3) I also think that "utility" is a bad name. Is "singleton" two letters >>> too long? >> >> Yes and not because "singleton" is longer. >> It just a bad name. >> :-) > > To clarify because of > > 1. the typo above (should be "It's just ..."); > 2. the preposition "it" used. > > I meant: "Singleton" is a bad name. I've given my reasons (the most recent attempt was to Charlie Clark). You give yours. :-) Gary ___ 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] singleton vs. utility (was Re: implementing zope.component 4.0)
On Nov 30, 2009, at 5:21 PM, Fred Drake wrote: > On Mon, Nov 30, 2009 at 5:14 PM, Lennart Regebro wrote: >> True. For me utilities are tools. Like CMFs portal_whatever. But in >> Zope3 even small stupid singleton objects are utilities in some cases, >> and that is confusing for a beginner. > > I wonder how many typical Python programmers know the term > "singleton". Point taken, somewhat. That said, it's a term easily used on the Launchpad team at least. In contrast, I have to explain "utilities"...and, since "utility" means very little (Python is a utility from some perspectives), I use "a way to register and get singletons" as my explanation, which seems to work quite nicely. > Though it's not unusual for there to be exactly one > instance of a class in a process, it's pretty unusual to think about > that as a valuable aspect of a class. Which for the traditional > definition of singleton, it very much is. Point taken, somewhat. We don't have a single instance of a class. We have a single instance of an object providing an interface, in a given context (registry and "name"space at the moment). This is an extension of the idea of singletons, based on interfaces rather than classes. Similarly, classic adaptation is an extension of type casting, based on interfaces. To my mind, and in my explanations, what we actually use adaptation/multiadaptation for is an extension of class instantiation, based on interfaces to describe the output rather than classes. These comparisons are leaky, but these are all mostly leaky in the same, limited way: you replace classes with interfaces. I'm trying to solve a real-world problem: I have to explain these concepts to people who occasionally encounter them in the bowels of the software they write on a daily basis. I want the relevant API to take less time to explain, and to be easier to remember with limited exposure. Clearly tying the APIs and concepts to familiar ideas is a common approach to that problem. Whatever the solution, the *problem* sounds a lot to me like users of Grok and BFG, for instance. > -1 for calling utilities singletons, since that has nothing to do with > their usage. > > +1 for calling them utilities, since that has everything to do with > how they're used. I don't love "singleton." I think it is better than "utility." I agree at least that it probably isn't better enough to introduce confusion. I'd be more insistent on "singleton", or finding a better term than either of them, if this were a fresh API. Gary ___ 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] adapter vs factory Re: implementing zope.component 4.0
On Nov 30, 2009, at 5:14 PM, Lennart Regebro wrote: > On Mon, Nov 30, 2009 at 22:40, Gary Poster wrote: >> Then to the multiadapter concern I raised, all my real-world examples of >> adapters are to adapt one object so it can be used in a certain way (to >> integrate with another kind of object). Power adapters, for instance, adapt >> a plug (required interface) so it can plugged in to the wall (output >> interface). Is there a common real-world example of this for >> "multiadapters"? > > Yup. > http://www.amazon.co.uk/Scart-Adapter-Switchable-Plug-Socket/dp/B00077DC6A > > Audio + Video in: SCART out. :) heh. And Shane's example was more commonplace. I still think this is unusual, or in Shane's example, not something that people think of as a multiadapter. But as said, to Fred, point partly taken. :-) [snip utility/singleton] > > >> That said, and to repeat, I mind "adapter" more than "utility." > > But adapter is really what it is. OK, Multiadapters are evidently > complicated... But is it really so complicated that we should throw > away the commonly accepted GoF for what clearly are adapters? How is > it less confusing to call IFoo.instance(x,y) than IFoo.adapt(x,y) or > even IFoo(x,y)? I am very much in favor of IFoo(x, y). That makes me very happy. It looks mostly like you are instantiating a class, except that it looks a bit funny: in my view, it is a reasonably good leaky abstraction for what is going on. People also like the compactness of the spelling, in my discussions. They also remember it very well, even over long periods of not using the API. This is a big deal. Backwards compatibility is the problem. I need to go have a life. :-) Talk to you all tomorrow. Gary ___ 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
On Dec 1, 2009, at 9:54 AM, Chris McDonough wrote: > Martijn Faassen wrote: >> ... > I am also in favor of unifying adapter and utility lookup. Or at least > creating a more normalized API. I guess it is no surprise that I am in favor of a normalized API but against the unification. > On the syntax of the change: [...] I followed vaguely. This was about unification, correct? > On the semantics of the change: > > Personally I think that it's a fantasy to believe that the difference between > an object created via a factory on-demand and an object simply returned > should > *never* matter to a caller. You may not want the caller to need to care, and > it may be inconvenient to take into account circumstances where the caller > needs to care. But because this is Python, the caller still often does need > to > care. Again, no surprise that I agree with this and following. Gary ___ 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
On Dec 1, 2009, at 8:21 AM, Martijn Faassen wrote: > Hi there, > > I'd like to summarize the options I've seen appear in the discussion so far. > > We have the following options: > > 1) introduce a new method, such as "instance()" or "lookup()" on > instance. It unifies utilities with adapters. We can make it do whatever > we want without worrying about backwards compatibility. > > 2) introduce several new methods that distinguish between utility and > adapter lookup. We can make them do whatever we want without worrying > about backwards compatibility. > > 3) call the interface, which unifies adapter and utility lookups. Use > tuples for multi adaptation. We think could make this work without *too* > much backwards compatibility issues (pending research on how prevalent > tuple adaptation really is). In the long term we can even map out a > deprecation strategy that can smoothly migrate us to a "multi argument" > approach. > > 4) call the interface, which unifies adapter and utility lookups. Use > multiple arguments for multi adaptation. The backwards compatibility > obstacles are largest here as we already have the "default" argument. > We'd need to introduce multiple "modes" to selectively upgrade. You are leaving out the variants of 3 and 4 that allow calling the interface to support multiadaptation, but do not unify utilities. My impression is that I am not the only one who is not pleased with the proposed unification of utilities and adaptation. My impression is that we are nearing consensus on the variation of 3 that does not include utilities. Gary ___ 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] implementing zope.component 4.0
On Dec 2, 2009, at 8:33 AM, Fred Drake wrote: > On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote: >> To be honest, I just don't see why this whole singleton business shouldn't >> be orthogonal to the concepts of the component architecture. > > Well said. If an application cares about singleton creation or > ownership of factory-returned objects, it can describe those > requirements using interfaces. You are arguing for the unification of utilities and adapters? Gary ___ 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] implementing zope.component 4.0
On Dec 2, 2009, at 8:58 AM, Fred Drake wrote: > On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster wrote: >> You are arguing for the unification of utilities and adapters? > > No. I'm arguing not to conflate utilities with the singleton pattern > or adaptation with ownership of the resulting adaptation. OK. I have given up on the singleton presentation. I still think that it has as much validity as comparing adaptation to type casting, but let's leave it. It's dead. The "ownership" issue is just a small part of the larger picture that I address below. On Dec 2, 2009, at 9:19 AM, Thomas Lotze wrote: > I think the difference between these two perspectives may have to do with > why some people in this discussion confuse (as I see it) the concepts of > instance vs. factory registration and adapter vs. utility lookup. It's not a matter of confusion in my mind. It's a matter of trying to present these ideas in a way that people who do not use these ideas frequently understand and remember easily. I think the difference is between the perspective of people who use these tools day in and out, and are already comfortable with them; and the perspective of people who want to make the ideas easy to use and remember for introductory and casual/intermittent usage. If Python presented classes as abstract callables that can do whatever the heck you want, I don't think that would be particularly useful. That's what they are, but we mostly use them as factories. They are generally explained as factories. The exceptions are that: unusual exceptions to the rule and basic idea. Instance vs. factory registration is a clean way of distinguishing between "utilities" and "adapters". "adapters" is IMO not an accurate description of how we use "multiadapters" (and certainly not "subscription adapters," which is another whole ball of wax that has a different solution IMO). Without this distinction, AFAICT either you want to conflate the ideas, or you have a concept of the differences between the two that is more esoteric than I think is useful. I get the impression that it is on the second point of those that we disagree. Gary ___ 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] ZCA summary so far...
...from my perspective. = Things vaguely approaching consensus = == General == There's a consensus that changes to the ZCA need to be backwards compatible. The practical definition of that varies for different people. == Syntactic == === Tuple multi-adaptation === Example: IFoo((bar, baz)) == z.c.getMultiAdapter((bar, baz), IFoo) - It has the most consensus of any proposed change so far. - It is concerning because it breaks backwards compatibility in two real world use cases from the very small set of Zope users who actually watch zope-dev. There is a workaround spelling at least, but it is ugly (i.e., what was ``IFoo((bar, baz))`` will need to become ``IFoo(((bar, baz),))``). - It is easier to remember than ``z.c.getMultiAdapter((bar, baz), IFoo)`` (I always have to look up the order of arguments for getMultiAdapter myself) but not as easy to remember as ``IFoo(bar, baz)``. It introduces yet another spelling of the same thing (e.g., ``IFoo(bar)`` is the same as ``IFoo((bar,))``. == Utilities available from interfaces == As far as I can tell, no one is against this generally, and several people are for it. Some people are against the syntax that has been proposed for this that merges utilties and adapters (see "No consensus" section below). An alternate syntax was proposed involving a ``utility`` callable. This made the most sense when it was paired with an ``adapters`` (or ``factory`` or ``new`` or ``instance`` or ``create``) callable, which contradicts the consensus of the "tuple multi-adaptation" section above. = No consensus AFAICT = - Utilities and adapters should be merged. - We care significantly about new and casual users and perceive that the current API does not serve them well. - Adapters are usually used as factories, and utilities are used as instances, and it is valuable to present them that way. Related: the term "adapter" buys us little and costs us more than nothing among new and casual users. = Rejected = - Utilities should be called singletons. ___ 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] ZCA proposal
I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) = Why? = - This is a significant improvement in terms of being memorable, as far as I'm concerned. It's also briefer, which is related. - It uses the terms we've already taught. - It is entirely backwards compatible. We don't have to poll the world and hope we didn't miss anyone. - We can make the call syntax for ``adapt`` take multiple arguments. - It is symmetric-ish. - It would potentially allow a place to hang debug/analysis calls, as I showed earlier, but let's not have that debate yet. I can put those somewhere else if I need to. = Why not tuple multi-adaptation in the __call__? = I'm somewhat surprised that some who have been loudest about not breaking backwards compatibility are OK with breaking this, given the two reports from the very small sample we have here of users. I think it is unnecessarily risky for minimal gain, particularly when we have another reasonable option. = But Gary, I thought you didn't like ``adapt``? = No, I don't. I think it is a hindrance to understanding, and I would prefer ``instance``, for example (or maybe ``create``?). That said, people disagree with me. Going along with ``adapt`` but getting this new syntax gets me a lot of improvements from my perspective. I think people on the Launchpad team would be happy with this. I would explain ``adapt`` as "look, it's a factory," but, oh well. Progress usually means compromise. = But Gary, I thought you didn't like ``utility``? = No, I don't. I already gave up on that one, since I didn't have an answer better than "singleton" and I acknowledge that it is not great (either, for different reasons). Gary ___ 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] ZCA proposal
On Dec 2, 2009, at 11:09 PM, Martin Aspeli wrote: > Gary Poster wrote: >> I think I could get fully behind the following proposal that others >> have made (Shane I think was one of several?). >> >> IFoo.adapt(...) >> >> IFoo.utility(...) > > I could get behind this too. > > We'd need the current IFoo(context, default) for single adaptation to > continue to work, and I *wouldn't* deprecate it with a warning, since > it'd just lead to a lot of warnings. We'd obviously also want the > existing get*() methods to continue to work. Not sure which get* you mean (get* and query* in ZCA?) but generally agree that we are talking about adding, not removing. Gary ___ 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] ZCA summary so far...
On Dec 3, 2009, at 1:54 AM, Chris McDonough wrote: > My $.02 is here: > > http://www.plope.com/Members/chrism/zca_thoughts_summary I was going to comment on your blog, even though it was separate from the mailing list, but then I couldn't register an account, so here I am. I agree with a decent chunk of what you say. I guess my experiences working with new and casual ZCA users in Launchpad are somewhat similar to your BFG experiences. I'm very interested in working on changes in the underlying registry. Like you (I think), I'd also like to support the ability for using classes and abcs for specs. I have some work in that direction. I also want a better debugging API, which I have also investigated. We might disagree on the specifics, but it sounds like we're similar in broad desires there. I also agree with many of your perceptions of what we have: the experimental package I have started that subsumes the jobs of zope.interface and zope.component is called "pluggable," which echoes one of your points. I don't think replacing these packages is a practical way forward, but it helps me think and imagine. I think that moving forward might be easiest to do by making the adapter registry pluggable in zope.interface and zope.component, and working on this in another package.At that point, interested users of zope.interface and zope.component could choose to use our registry (and perhaps it might evolve to become the "blessed" registry at some point); and we could provide alternative ways of using the package, separate from zope.component and zope.interface. We should collaborate. In my "copious spare time" I would like to call you and see if you and I can at least agree on some experiments in this direction. I'd like it if my work had some chance of uptake in BFG. I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. Gary ___ 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] internal improvements to zope.component Was: ZCA summary so far...
On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote:
> Gary Poster wrote:
> [snip]
>> I personally think these efforts do not make the potential consensus
>> on ``adapt`` and ``utility`` methods any less interesting: they would
>> be a concrete win for my users.
>
> I agree with much of what Gary is saying here.
>
> My ideas:
>
> * I'd like us not to make any lookup API improvements on looking up
> things dependent on underlying refactorings.
I didn't follow this until I squinted at it and came up with
"I'd like us not to make any API improvements on looking up things dependent on
underlying refactorings."
That sounds reasonable.
> * I'd like to see some underlying refactorings in
> zope.component/zope.interface.
A broad agreement, but an agreement nonetheless.
> * I'd also like to see a better registration API
I don't have that pain point ATM, but I can vaguely see where one might.
> * documenting this clearly (and perhaps in advance of any actual work)
> is important.
+1 on documenting.
-1 on not allowing some experiments to happen first.
> * I'd like to keep zope.interface and zope.component backwards
> compatible and still benefit from the improvements.
+1
> * Therefore, any rethink of the internals can be substantial but not so
> fundamental as to drop interfaces or the ideas of adaptation and utilities.
I'm +1 on that as long as it can be rephrased to "...can be substantial but not
so fundamental as to drop interfaces or the *support for* the ideas of
adaptation and utilities."
> * Preferably I would like these things to take place in zope.component
> and/or zope.interface. Experimental packages are all right, I guess, but
> I wouldn't want them to be permanent. Let's keep the user community
> together on this one, please.
I am interested in a package that gives the pluggable functionality I want but
that does not depend on zope.component, but that zope.component can or does
depend on.
I am not a fan of design by committee.
I do think a community ("committee") often has better ideas than a single
person. Certainly I feel comfortable saying that when the single person is
myself.
I reconcile these positions by feeling that a very small number of people
should design packages initially. Then the community can take them, take them
and modify them, or leave them (ideally learning from them).
> * I *also* would like to take a range of optional dependencies out of
> zope.component, however. The ZCML directive implementations in particular.
I don't have that pain point ATM, but I can vaguely see where one might.
>
> * but I'd be fine if we got a better API and implemented the old APIs on
> top of these.
>
> * and we might eventually deprecate the old APIs.
Agreed.
Gary
___
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 )
