Re: [Zope-dev] github etiquette
On Tue, Sep 17, 2013 at 8:58 AM, Marius Gedminas wrote: > On Tue, Sep 17, 2013 at 07:47:42AM -0400, Jim Fulton wrote: >> On Tue, Sep 17, 2013 at 7:00 AM, Marius Gedminas wrote: >> >> Now that I mended the pull request, should I merge the pull request >> >> myself? Or is the current etiquette that someone else should merge >> >> the pull request? >> > >> > I think it's fine to merge own pull requests, provided that somebody >> > +1'd it. (Or if nobody cared for a couple of weeks, even after asking >> > for feedback on the list.) >> >> I strongly prefer that the reviewer do the merge. > > FWIW the only reason I'm in favour of self-merges is that this > short-circuits the "have you signed the ZF committer agreement?" dance. > Only people who have can merge. Sorry, I don't understand the point you're making. > I also feel silly when I ask this question from people with very > familiar names. (I feel that I have to do when I don't see ZF > membership on their GitHub profile.) So are you saying you don't merge other people's code because you don't want to ask if they're contributors? I can understand this, but I'd still try to encourage a more review-centric workflow. Also, if a change is trivial, the PR doesn't have to be from a contributor. I understand that triviality isn't always clear. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] github etiquette
On Tue, Sep 17, 2013 at 8:32 AM, Jan-Wijbrand Kolman wrote: > On 9/17/13 1:47 PM, Jim Fulton wrote: >> >> I strongly prefer that the reviewer do the merge. >> >> I'd also really like reviewers to take their responsibility >> seriously, making comments and suggestions where appropriate. >> >> Software review, done well, improves the software, and, more >> importantly, improves the developers. > > > I agree - I know I get better from recieving feedback :-) > > Is this "reviewer role" something someone takes upon himself? I mean, if I > see a pull request for a code base that I know, I could review the request? These are good questions. I probably don't have satisfying answers. The short answer is that I think people who contribute to a project should view review as one of their duties. For better or worse, this is somewhat informal. If you don't get a review in a timely manner, try posting to the appropriate mailing list to request a review. > Or do we acknowledge a group of people that generally do reviews (again > formally of informally, I don't mind, I'm not looking for "official > procedures")? No. > p.s. Another thing I noticed: some of the discussion about changes and > patches and fixes now shift from the mailinglist to github. This is fine, I > guess. Yes, IMO. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] github etiquette
On Tue, Sep 17, 2013 at 7:00 AM, Marius Gedminas wrote: ... >> 2) fork the repository, make a branch in the fork, do my work, push >> the changes to my fork, and issue a pull request. >> >> The latter is what I did, without explicitly asking for feedback. >> Luckily someone did give me feedback (thanks!) :-) > > I think a pull request is right. Yup. > It doesn't matter much if the branch you're asking to pull is in the > main repository or in a private fork. Yup. (Apparently, number of forks is a way some people keep score on github, so I'll cynically say a fork is better.) >> Now that I mended the pull request, should I merge the pull request >> myself? Or is the current etiquette that someone else should merge >> the pull request? > > I think it's fine to merge own pull requests, provided that somebody > +1'd it. (Or if nobody cared for a couple of weeks, even after asking > for feedback on the list.) I strongly prefer that the reviewer do the merge. I'd also really like reviewers to take their responsibility seriously, making comments and suggestions where appropriate. Software review, done well, improves the software, and, more importantly, improves the developers. > >> My apologies in case I missed an obvious document or reference >> somewhere that describes the way "we" should work with the >> zopefoundation's codebase... > > Can we please get the http://foundation.zope.org/ website source on > GitHub, so it becomes maintainable by the community? Oh yes, please! Unfortunately, this will require moving from silva to sphinx. It will also entail separating the public sites from private documents. (The above isn't meant to dis silva, it's just not a good fit for zopefoundation.org.) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Important! buildout 2.1.1 released, prepare for distribute 0.7 and buildout 2.2
Distribute/setuptools 0.7 bring some big changes. These changes can't be handled by buildout's normal automatic upgrade mechanism. For this reason, it's important to do one of the following if you're using buildout 2: - Pin your distribute version to <0.7dev or to some other 0.6 version. - Upgrade to buildout 2.1.1, which was just released. This will prevent automatic upgrade to distribute 0.7 or buildout 2.2. To upgrade, imply rerun your existing buildout scripts. - Be prepared to re-bootstrap your buildouts with the the new buildout 2.2 bootstrap script, which will be released soon after the release of distribute 0.7. -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] download.zope.org down
Looks OK now. Maybe someone fixed it. Jim On Tue, Jun 11, 2013 at 7:24 AM, Andreas Jung wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi there, > > download.zope.org seems to be. > > Bad because there is Plone hotfix release scheduled > for toda 15h UTC... > > Andreas > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQGUBAEBAgAGBQJRtwjYAAoJEADcfz7u4AZjoncLvRE3dS0RrWZmHmQvQ8WMAOxc > 09JwPY9HkcD4ghblZv/jaLIHVpcSs3H6RU+bf+vGLiw6zEnYphKu7oZI9avjlY7Q > NEfRiC1QLlyE8L/m45PL9nH8MzF+LhidOGRIxp989ME/ol8dOBmxoF4Fp7st5TZ5 > nyidwjC+rKlywaoInvFVwgizezLxyt8ljBLHwOVS7T8Tr+xrYmMC9H4ifdWQvj/T > +H/cF9byGWrne8tJIqCYzIvXC7vAMYk9qOfD38lCx4+F/v1xYG4EtYyGTHLSJXFV > KS8j14PY248ZF0N/6OgNnw9EXz3WrNNehPz3h8iyzhnZgu/TvNXzSjqoKPAI+7z5 > ZdcHkvM3HXdUZstMUy2qPa62J0T0MH7Sjo3N4Hn49+1ILo5r7fI1oZcg3/b9F8IT > wFuWibMN3G7YUMgqFeDqkF1gb9+rWz5b17CzO9AgzMuvK/B3WZLJCGGB28Wsk74e > /0dvKUjjb58LBooXNoDFIgVxrPEoQnI= > =8HlV > -END PGP SIGNATURE- > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) > -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Forcing buildout to download sdist packages only
On Thu, May 30, 2013 at 7:26 AM, Andreas Jung wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi there, > > I have a buildout where I am using the 'pyamp' module. > > https://pypi.python.org/pypi/pyamp > > zc.buildout on my Raspberry PI tries to download and install > the binary release package for Linux. Is there a way to > force buildout to use source code distros only? No, although a prefer-source option has been discussed. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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 for javascript
On Wed, May 22, 2013 at 12:32 AM, Andreas Jung wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Like always: you're thoughtd and reasoning are years behind of what > people actually do today or using nowadays. I remember your pointless > discussions on ZClasses - years ago, years after we kicked ZClasses > completely. We (I) dropped the ball on ZClasses. They were for an audience that was important in the early days of Zope and that we turned our backs on. IMO, he was right to champion them. I think if we'd paid attention, Zope would be more relevant today than it is now. > I suggest to move on to a Javascript community and continue > do discuss there. Nowaday we have framework like backbone.js, angular.js > on the client for doing state-of-the-art client-side JS implementations. > Or stuff like Obviel (from Martijn Faasen, a long time contributor of > Zope). Don't take it personally but all your questions and communication > over the last decade it based on very little technical insight and > experience. Application design and decisions should be left > to other persons. How can he not take it personally when you start and end by insulting him. Your response is inappropriate and mostly non-technical. If you're uninterested in his proposal, just be quiet. Maybe others are or it will die out. If you want to help by respectfully providing technical arguments, then that's fine too. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Fwd: Patch for zc.zk
On Tue, May 14, 2013 at 9:12 PM, Dave Cahill wrote: > Hi Jim, > > Thanks for the response and advice. > > My use case is purely export / dump (including ephemeral nodes) and load - I > looked at kazoo, but it didn't seem to provide that functionality, where > zc.zk did. > > Do you know where the dump/load functionality would fit in future plans? Or > if there's a better option for dump and load? I tried a few options > (zktreeutil crashed due to long strings, guano had issues with long file > names etc). I consider import and export of the tree models a core feature that will be ported to zk.service. Keep in mind though that it isn't intended as a general-purpose ZooKeeper export/import facility. I think if you want to export and import arbitrary ZooKeeper data, written by any application, I'd recommend writing something simple that exports and imports to something like marshal, pickle, or json. Writing such a tool should take a few minutes, not count tests, which brings it up to a few hours. ;) >> Maybe. Not sure nodes with spaces in the names is a good idea. This is particularly in the context of zc.zk's service model. > You're right that as a client, putting spaces in node names is not a great > idea because many tools don't handle them. But I figure if the client has > already written nodes with spaces to Zookeeper, the dump tool should dump > them that way instead of failing. Perhaps. Again, if you want a dump tool that losslessly dumps and loads arbitrary node data, I would use something simpler and less focused than zc.zk's export/import format. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Fwd: Patch for zc.zk
On Tue, May 14, 2013 at 6:02 AM, Dave Cahill wrote: > Hi, > > Reposting to the zope-dev list - does anyone know if zc.zk is still active? Yes, but I have lots of other projects. Don't expect instant responses. > > I have another patch to fix importing nodes with spaces in the name, but > maybe > I should just fork it instead and apply my fixes there. :) Maybe. Not sure nodes with spaces in the names is a good idea. In terms of plans: - You should only use zc.zk for it's original use cases of service registry and discovery. For anything else, you should use kazoo. - I plan to port zc.zk to kazoo. This hasn't been an urgent priority up to now (although it's been getting more so). I was hoping to get a student to work on it, but that didn't work out. If someone is looking for a project, I'd be happy to have volunteers. :) There are two projects waiting for work: https://github.com/python-zk/zk.fauxzoo This is a replaceable mock, similar to what zc.zk provides. It should allow application tests with or without connection to a ZooKeeper server. https://github.com/python-zk/zk.service This is a port of the functionality in zc,zk that's absent from kazoo, including the high-level data model and service registry and discovery. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Github tip to get less github spam:
Visit: https://github.com/watching Either unwatch all or selectively unwatch repositories you're not interested in. (If you stop watching all, there's a lot of clicking to then watch repositories again.) Uncheck autowatch (I wish I'd done this a couple of weekes ago :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] [zopefoundation/zope.security] 82fd54: Changed strategy to hide wrapped to not use the se...
On Tue, Mar 12, 2013 at 8:30 AM, Stephan Richter
wrote:
> On Monday, March 11, 2013 10:33:30 PM Tres Seaver wrote:
>> > Yep, saw that. There are some uncovered lines for which I have to add
>> > tests left. Also, I just noticed while prorting zope.publisher to PyPy
>> > that proxies cannot be adapted, which is a big issue for any view
>> > libraries.
>>
>> Ouch. That "lying about my type" bit is hard to get over.
>
> I was thinking about dynamically creating proxy classes. Something along the
> lines of:
>
> class PyProxy(object):
>
> def __new__(cls, orig):
> ProxyForOrig = type('ProxyForOrig', (cls, orig.__class__))
> return ProxyForOrig(orig)
>
> That should also help us with our 3-arg pow() call
>
> What do you think?
Sorry, why do you want to adapt proxies? The "lying about class",
which is arguably not lying, is intentional and facilitates adapting proxied
objects.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm
___
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] windows egg/exe packages on PyPI?
On Wed, Mar 6, 2013 at 7:10 AM, Adam GROSZER wrote: > Hello, > > Just got a request that winbot should prepare .exe's for windows. > > My question is, do we want exe AND egg or just exe for windows binary > packages? > > I think setuptools/distribute should work with an exe too, I doubt it. Have you tested it? > but veto me here > and now. Unless you prove that they're equivalent, both please. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Moving to Github: authors.txt (and svn12git.py)
I've created a private subversion repository containing the authors.txt file needed when converting subversion repository to git. svn+ssh://svn.zope.org/repos/2git It's a small repository that you can check out directly: svn co svn+ssh://svn.zope.org/repos/2git I've also included a small python script, svn2git.py. It: - builds on the git svn plugin, which you must have installed. - doesn't require that you have a local copy of the subversion repository. - is more reliable than the ruby version - It usually does it's work in a few minutes. - It has run into difficulty with one project, ZEO, where it got into some look and didn't finish. This is the script I use and I recommend it for individual repositories. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Temporary write access to moved SVN packages needed
On Tue, Feb 19, 2013 at 12:52 PM, Stephan Richter wrote: > Hi Jim, > > I temporarily need access to the following packages to remove the trunk code > and add a MOVED_TO_GITHUB file: > > * zope.deprecation > * zope.event > * zope.exceptions > * zope.hookable > * zope.i18nmessageid > * zope.interface > * zope.location > * zope.proxy > * zope.schema > * zope.testing Done Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] zdaemon test dependencies
On Wed, Feb 13, 2013 at 12:16 PM, Stephan Richter wrote: > On Wednesday, February 13, 2013 09:27:46 AM Jim Fulton wrote: >> > Both options are fine with me. Your choice. :-) >> >> Ah. For now, I'd skip the JS-integration tests for Python 3. > > Okay, all done. Can you make me an PyPI owner of zc.customdoctests? My > username is 'srichter'. Done. Thanks. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] zdaemon test dependencies
On Wed, Feb 13, 2013 at 9:39 AM, Stephan Richter wrote: > On Wednesday, February 13, 2013 09:27:46 AM Jim Fulton wrote: >> OT, will you volunteer for the ZF board? > > I would. Thanks! > Feel free to nominate me, Done. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] zdaemon test dependencies
On Wed, Feb 13, 2013 at 9:21 AM, Stephan Richter wrote: > On Wednesday, February 13, 2013 09:13:52 AM Jim Fulton wrote: >> On Wed, Feb 13, 2013 at 8:36 AM, Stephan Richter >> >> wrote: >> > On Wednesday, February 13, 2013 07:16:03 AM Jim Fulton wrote: >> >> I would make a javascript extra for customdoctests that requires >> >> spidermonkey. >> > >> > Okay, and then have two test runners, one running without spidermonkey and >> > one with and conditionalize the tests? >> >> I wouldn't bother. > > But in order to test zc.customdoctests' Py3 compatibility I need to run its > tests. So I have 2 choices: > > 1. Remove all spidermonkey integration tests. > 2. Run all spidermonkey integration tests only on Python 2. > > Both options are fine with me. Your choice. :-) Ah. For now, I'd skip the JS-integration tests for Python 3. OT, will you volunteer for the ZF board? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] zdaemon test dependencies
On Wed, Feb 13, 2013 at 8:36 AM, Stephan Richter wrote: > On Wednesday, February 13, 2013 07:16:03 AM Jim Fulton wrote: >> I would make a javascript extra for customdoctests that requires >> spidermonkey. > > Okay, and then have two test runners, one running without spidermonkey and one > with and conditionalize the tests? I wouldn't bother. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Style guide update?
On Wed, Feb 13, 2013 at 1:53 AM, Marius Gedminas wrote: > On Tue, Feb 12, 2013 at 05:20:14PM -0500, Fred Drake wrote: >> At one point, we had a style guide that recommended simple "import >> " import statements for Zope code: >> >> http://wiki.zope.org/zope3/ZopePythonStyleGuide > > That page only mentions 'from whatever import *' which everyone will > agree ought to be avoided. It doesn't say anything about 'from whatever > import somename' (except that you shouldn't import somename if you're > not going to use it). > >> Today, I'm noticing a lot of commits with the change note "Normalize >> imports" that change all imports to "from import whatever", >> like this one: >> >> >> https://github.com/zopefoundation/zope.security/commit/115691fce9c80a340f271410eec2964c92fbace4 >> >> Do we still have an agreed-upon style guide, or are we moving to a >> last-touched-by approach? I agree that Tres' changes don't seem to violate the style guide, such as it is. I strongly prefer Fred's style of imports -- avoiding from imports except for things that are used a whole lot. I think it makes the code easier to read because you don't have to wonder where names are coming from. However, it's hard to object when someone's doing something that needs to be done, porting to Python 3, that I don't want to spend my time on. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] zdaemon test dependencies
On Tue, Feb 12, 2013 at 11:10 PM, Stephan Richter wrote: > Hi Jim, > > I am trying to get closer to get zope.site ported to Python 3. This requires > porting of ZODB, which in turn requires zdaemon to be ported. So far so good. > But then zdaemon has zc.customdoctests as a test requirement, which then needs > python-spidermonkey. That sounds like a bug. > Since we do not control python-spidermonkey, I would like to break the > dependency path somewhere. +1 > I was thinking about having the zdaemon tests that > require zc.customdoctests only run in Python 2. Does this sound good? No. I would make a javascript extra for customdoctests that requires spidermonkey. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] PyPI access to zc.lockfile
On Tue, Feb 12, 2013 at 3:35 PM, Stephan Richter wrote: > On Tuesday, February 12, 2013 01:29:43 PM Jim Fulton wrote: >> > can you give me access to zc.lockfile, so I can upload a new release? >> >> PyPI id? > > srichter Done. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] PyPI access to zc.lockfile
On Tue, Feb 12, 2013 at 12:35 PM, Stephan Richter wrote: > Hi Jim, > > can you give me access to zc.lockfile, so I can upload a new release? PyPI id? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security on github?
On Mon, Feb 11, 2013 at 3:39 PM, Stephan Richter wrote: > On Monday, February 11, 2013 03:37:17 PM Jim Fulton wrote: >> > It seems to be readonly already, so I cannot remove the files. >> >> Sorry. Fixed. Can you try again please? > > All done. Thanks. Back to read only. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security on github?
On Mon, Feb 11, 2013 at 3:29 PM, Stephan Richter wrote: > On Monday, February 11, 2013 03:19:54 PM Jim Fulton wrote: >> > 1. Can we delete the contents of zope.security on svn.zope.org? >> >> Please remove the contents of trunk and add a MOVED_TO_GITHUB file in >> trunk and in the project root with the git repo url. >> >> When that's done, I'll make the project read only. > > It seems to be readonly already, so I cannot remove the files. Sorry. Fixed. Can you try again please? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security on github?
On Mon, Feb 11, 2013 at 3:14 PM, Stephan Richter wrote: > Hi everyone, > > I was just about to start porting zope.security using the SVN version, when I > noticed it is already on Github and Tres has even worked on it today. So 2 > things: > > 1. Can we delete the contents of zope.security on svn.zope.org? Please remove the contents of trunk and add a MOVED_TO_GITHUB file in trunk and in the project root with the git repo url. When that's done, I'll make the project read only. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Examples of ZODB.event
On Mon, Feb 11, 2013 at 11:45 AM, Jean-Daniel wrote: > Hello, > > I would like to build a config repository on the ZODB for an appliance where > many processes would boot and talk to at boot to load their configuration. > > Some processes might modify or add new conf, and some different component > should take this change of configuration into account. > > Is there any ZODB.event example app that I could read from? ZODB.event is a > little too low level for me. > > I wish the subscribers would get a notification message like: > > - property modified. Ex: '(VideoComponent', 'server_port') > - original value, new value. Ex: '8080', '1234' This isn't a feature in ZODB yet. Sorry. When there is such a feature, it will be lower-level than that. You'll be able to find out that an object changed, but not what part of the object changed. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] git migration: Here's the script I use to convert subversion projects to git
I've been holding off making it more public until I polish it further but there's really no reason to hold off, since I'm unlikely to do more with it soon: https://gist.github.com/4683891 Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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.ssl ca chain
On Fri, Jan 25, 2013 at 12:00 PM, Jim Fulton wrote: > On Fri, Jan 25, 2013 at 11:22 AM, Senner, Talin > wrote: >> Would someone that has access be able to update zc.ssl and release a new >> version: >> >> http://svn.zope.org/zc.ssl/trunk/src/zc/ssl/certs.pem >> >> with a new version of ca root certificates (something say from a latest >> linux release from /etc/ssl ). The current cert chain is over 5 years old. The certificates in zc.ssl haven't changed. > I'll take care of this. Note that we (ZC) will likely move to requests and > stop maintaining zc.ssl. There's nothing to do at this point. If you want more root CAs, I suggest using requests, or forking zc.ssl and adding certs to your fork. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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.ssl ca chain
On Fri, Jan 25, 2013 at 11:22 AM, Senner, Talin wrote: > Would someone that has access be able to update zc.ssl and release a new > version: > > http://svn.zope.org/zc.ssl/trunk/src/zc/ssl/certs.pem > > with a new version of ca root certificates (something say from a latest > linux release from /etc/ssl ). The current cert chain is over 5 years old. I'll take care of this. Note that we (ZC) will likely move to requests and stop maintaining zc.ssl. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Building/Testing persistent package with tox
On Fri, Jan 11, 2013 at 11:05 AM, Stephan Richter wrote: ... > BTW, the current bootstrap.py file does not work with Python 3. Are we not > going to support buildout with Python 3 or what's the goal/story here? Buildout 2, which is still in alpha, but all I use works with Python 3. Use: http://downloads.buildout.org/2/bootstrap.py and don't forget to use -t, since buildout 2 isn't final. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Becoming a "zopefoundation" member on GitHub
On Fri, Jan 11, 2013 at 10:55 AM, Stephan Richter wrote: > Hi everyone, > > what are the necessary steps to become a Zope Foundation organization member > on GitHub? I would like to try moving a small product there to test the > migration. You should have gotten an email from me a a few weeks ago requesting your github email. (It turns out I needed your id too.) Perhaps we didn't have an up-to-date email address for you in our database, or maybe it got files as spam. :) Please send me (privately) your github email and id. If any other contributors didn't get an email from me and want write access to the github repositories, please send me your github id and email. WRT moving or creating repositories, an unfortunate miss-feature of github is that developers with push access can't also create repositories. (This is one of the reasons that ZC uses bitbucket.) You'll have to ask someone (like me) to do that for you. I don't think we've formalized the process for this. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Building/Testing persistent package with tox
On Fri, Jan 11, 2013 at 10:54 AM, Stephan Richter wrote: > Hi guys, > > I have just tried to build/test persistent with tox and it fails with the > following error message:: > > IOError: [Errno 2] No such file or directory: '/tmp/pip-u7jE1n- > build/CHANGES.txt' > Complete output from command python setup.py egg_info: > Traceback (most recent call last): > > File "", line 16, in > > File "/tmp/pip-u7jE1n-build/setup.py", line 29, in > > open(os.path.join(here, 'CHANGES.txt')).read()) > > IOError: [Errno 2] No such file or directory: '/tmp/pip-u7jE1n- > build/CHANGES.txt > > This is indeed correct, since the ZIP package archive created by tox in > ./.tox/dist does not include any txt files. > > I use the following command to run tox: > > $ tox -e py27,py32 > > How do others run tox? The project needs to be updated with a manifest that causes .txt files to be included in builds. (Look at zc.buildout for an example.) I planned to do this, but hadn't gotten to it yet. I can probably do that this weekend. This is needed because persistent has moved to git and setuptools/distribute, **thankfully**, don't support git without a plugin. **Please**, no one fix this by adding the plugin, at least not for any projects I'm heavily involved it. I far prefer the explicit approach afforded by a lack of VCS integration. IMO, avoiding the setuptools/distribute VCS magic is a major advantage of moving to git. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Status of github migration
On Fri, Jan 11, 2013 at 10:34 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/10/2013 06:10 PM, Matthew Wilkes wrote: > >> Tres Seaver wrote: >>> What is needed is not scripts, but eyeballs: we need people who >>> know the various packages and*care* about getting them migrated to >>> github to step up. Softwward which doesn't have a champion willing >>> to do the work should stay behind on SVN. >> >> The community as a whole cares about having them all migrated to >> github. I'm sure this will happen the next time there's a sprint, just >> like lots of them got migrated (and subsequently deleted) at the zope4 >> sprint in San Francisco a few years back. > > The communite as-a-whole demonstrably does *not* care about many of the > projects on svn.zope.org. E.g.: > > https://mail.zope.org/pipermail/zope-tests/2013-January/070977.html > >> We need man-hours, sure, but not champions. Being blocked on working >> on the code because you're the first one to care about a package and >> subsequently have to learn how to do the migration is a crazy way of >> doing things. > > The foundation agreed to support moving projects to github, but that > isn't a blank check. For instance, if there is substantial interest in > having the projects pulled in by the current Plone buildout moved, make a > list of them, and recruit the folks to step up and help with the > migration for them. The effort requires includes doing the conversion, > checking the results *by hand*, landing the repository, and fixing > anything that breaks once you do (including stuff that breaks in projects > you otherwise don't care about). > > Any project that can't find somebody willing to do that work (that is > what I meant by a "champion") is better off staying on SVN: we don't do > ourselves favors by carrying all the unmaintained baggage of fifteen > years worth of development forward, just for "purity" / completeness / > whatever. +1 BTW (speaking of cruft), as someone who used/abused svn.zope.org as a generic open-source hosting service (when I should have used something like code.google.com, or bitbucket, or whatever), I wonder if there should be a process for petitioning to remove projects from the ZF repositories. (Maybe this only applies to me :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] How to signal that projects have moved to github
On Thu, Jan 10, 2013 at 12:02 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/10/2013 10:42 AM, Patrick Gerken wrote: >> I am in favor of removing the trunks. People who do not want to switch >> to git can still get the trunk by pinning to a specific revision. I >> run a CI tool and it is broken already because apparently a trunk has >> been deleted already. Thats not a bug, thats why I run the CI Tool. >> Would be stupid if I continue to test a trunk not in use. > > It isn't just CI: people may have projects running from SVN checkouts, > which we break without warning (the Plone devs have been notorious for > causing such breakage for years). I still think breakage is better. If they're using trunk, without pinning a revision, it must be because they want the latest code. They won't get that from svn. This is a case where I think it's better to fail in an obvious way. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Status of github migration
On Thu, Jan 10, 2013 at 10:54 AM, Hanno Schlichting wrote: > On Thu, Jan 10, 2013 at 3:59 PM, Jim Fulton wrote: >> >> On Thu, Jan 10, 2013 at 9:50 AM, Jens Vagelpohl >> wrote: >> > I did not choose to include or exclude any branch. The test migration >> > uses the package used to migrate most Plone packages from SVN to GitHub, >> > which uses svn2git underneath. If there's whole branches missing the >> > migration has obviously failed. >> >> I had a bunch of problems with ZODB and the ruby svn2git. > > > If you used a ruby tool, then you didn't use the same one as the Plone > migrations. Unfortunately there's at least two different tools named > svn2git. The one used by the Plone migrations is from the KDE community and > written in Qt. Some of the more useful info is at > http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git > > That tool doesn't really use git-svn. Instead it scan through all SVN > revisions, looks at the changed paths and matches those against a ruleset. > So you can tell it that both /foo/bar/trunk and /bar/trunk contain code that > goes into the final bar.git repo. Since you can manually influence these > rules, this tool tends to work better on projects which have moved their > location in SVN a lot. It also does a single scan through the entire SVN > repo and is able to generate many resulting git projects at once. Which made > it perfect for a mass-migration. > > git-svn or tools based on it, tend to work well on small projects that > always stayed in the same place, with the same structure. That's interesting. Not sure what I think about it (now that I have something mostly working and don't want to figure out something else :), but definitely worth thinking about. Thanks. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Status of github migration
On Thu, Jan 10, 2013 at 9:50 AM, Jens Vagelpohl wrote: > > On Jan 10, 2013, at 15:40 , Leonardo Rochael Almeida > wrote: >> I took a quick look at the Zope migration now and I think it's >> excellent. The only thing I'd add is that I'd also migrate branches >> 2.12 and 2.13 branches since they're all active, even if just for >> bug/security fixes. > > I did not choose to include or exclude any branch. The test migration uses > the package used to migrate most Plone packages from SVN to GitHub, which > uses svn2git underneath. If there's whole branches missing the migration has > obviously failed. I had a bunch of problems with ZODB and the ruby svn2git. That's why I wrote my own based on seeing what the ruby version was trying to do. Note that most of the heavy lifting is actually done by the git svn plugin. > > If you want to help you could try a migration with the attached Python script > that Jim wrote as a result of finding bugs in svn2git. I can provide you with > a suitable authors mapping file. I've been waiting to make the script more publicly available in a saner fashion until I've worked with it some more. I should just make it a gist. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] How to signal that projects have moved to github
I'd like us to agree on how we're going to indicate in SVN that projects have been moved to github. Here's an opening bid: - Replace contents of trunk with a single file MOVED_TO_GITHUB containing the URL if the project page in github - Copy above file to root of project. - Make project read only An argument against cleaning out trunk will break CI tools. This is also an argument *for* cleaning out trunk. :) Thoughts? There are a lot of other details of the migration that need to be worked out, like how folks should request migration and automating the conversion further. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Status of github migration
On Thu, Jan 10, 2013 at 8:39 AM, Jens Vagelpohl wrote: > > On Jan 10, 2013, at 14:37 , Jim Fulton wrote: > >> On Thu, Jan 10, 2013 at 5:48 AM, Jens Vagelpohl wrote: >>> For those packages that are fully migrated you will have obvious markers on >>> the package in svn.zope.org, such as the package being read-only. >> >> I don't think being read only is enough. Are people supposed to >> attempt commits to find out if a project is read-only? >> >> We should at least leave something like a MOVED_TO_GITHUB file in the >> project, in addition to making it read only. > > That's what I meant by "obvious marker, such as...". I did not imply making a > package read-only is the only marker. But that's all that has been done for some projects. (Sorry, I don't mean to be critical and I didn't raise the issue when it happened.) OTOH, it's been argued (I disagree :) that I did too much for the ZODB projects. I think it would be helpful if we agreed on what should done, so we have a standard play book. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] Status of github migration
On Thu, Jan 10, 2013 at 5:48 AM, Jens Vagelpohl wrote: > > On Jan 10, 2013, at 11:23 , Patrick Gerken wrote: > >> I wanted to fix some logging in Products.SiteErrorLog, but I am confused >> where to go to. >> >> zopefoundation on github has a small number of repos but not >> Products.SiteErrorLog. >> http://svn.zope.org shows me a web view of our old cvs server. >> >> There is something wrong. Can I help with something? > > > Going to http://svn.zope.org works fine for me. I see the expected SVN > repositories. > > The GitHub migration happens on an as-needed basis. Package maintainers may > request to have packages migrated or, like Jim and Tres are already doing, > migrate packages themselves. There is no full migration of all svn.zope.org > content. > > For those packages that are fully migrated you will have obvious markers on > the package in svn.zope.org, such as the package being read-only. I don't think being read only is enough. Are people supposed to attempt commits to find out if a project is read-only? We should at least leave something like a MOVED_TO_GITHUB file in the project, in addition to making it read only. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 34, OK: 17
On Sun, Jan 6, 2013 at 11:00 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/05/2013 08:00 PM, Zope tests summarizer wrote: >> [3]FAILED winbot / ZODB_dev py_265_win32 >> https://mail.zope.org/pipermail/zope-tests/2013-January/070946.html >> >> >> [4]FAILED winbot / ZODB_dev py_265_win64 >> https://mail.zope.org/pipermail/zope-tests/2013-January/070947.html >> >> >> [5]FAILED winbot / ZODB_dev py_270_win32 >> https://mail.zope.org/pipermail/zope-tests/2013-January/070948.html >> >> >> [6]FAILED winbot / ZODB_dev py_270_win64 >> https://mail.zope.org/pipermail/zope-tests/2013-January/070949.html >> >> >> [7]FAILED winbot / persistent_py_265_32 >> https://mail.zope.org/pipermail/zope-tests/2013-January/070961.html >> >> >> [8]FAILED winbot / persistent_py_265_32 >> https://mail.zope.org/pipermail/zope-tests/2013-January/070936.html >> >> >> [9]FAILED winbot / transaction_py_265_32 >> https://mail.zope.org/pipermail/zope-tests/2013-January/070953.html >> >> >> [10] FAILED winbot / transaction_py_265_32 >> https://mail.zope.org/pipermail/zope-tests/2013-January/070935.html > > Something is wedged on the winbot: these errors are all failures in the > buildout phase which look like:: > > c:\buildslave\transaction\build>call \ >"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCVARSALL.bat" \ > x86 > Setting environment for using Microsoft Visual Studio 2008 x86 tools. > The system cannot find the path specified. > program finished with exit code 1 Winbot needs to get these packages from github now. :) -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 6, OK: 17
On Mon, Dec 3, 2012 at 3:15 AM, Adam GROSZER wrote: > Hello, > > > On 12/02/2012 02:55 PM, Jim Fulton wrote: >> >> On Sat, Dec 1, 2012 at 8:00 PM, Zope tests summarizer >> wrote: >> >> ... >> >>> [1]FAILED winbot / ZODB_dev py_265_win32 >>> >>> https://mail.zope.org/pipermail/zope-tests/2012-December/069693.html >>> >>> >>> [2]FAILED winbot / ZODB_dev py_265_win64 >>> >>> https://mail.zope.org/pipermail/zope-tests/2012-December/069694.html >>> >>> >>> [3]FAILED winbot / ZODB_dev py_270_win32 >>> >>> https://mail.zope.org/pipermail/zope-tests/2012-December/069695.html >>> >>> >>> [4]FAILED winbot / ZODB_dev py_270_win64 >>> >>> https://mail.zope.org/pipermail/zope-tests/2012-December/069696.html >> >> >> This is due to the release yesterday. >> >> I can and will "fix" this, by providing a test extra, but this will only >> cause no tests to run. The fix may be needed for test of third-party >> packages that depend on ZODB3 [test]. >> >> The winbot needs to be modified to run the tests for persistent, >> BTrees, ZODB and ZEO separately. > > > I think the winbot does the right job. > Those tests are running against > > svn://svn.zope.org/repos/main/ZODB/trunk > > Now the tests pass as you added [test] back: Ah, there was a bug in the buildout config, which I just fixed. There's no way that ZODB should be depending on ZODB3, even in the buildout. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 6, OK: 17
On Sun, Dec 2, 2012 at 11:32 AM, Tres Seaver wrote: ... > If ZODB3 no longer has tests (as a pure meta-package), then dropping the > 'test' dependency and changing the buldout.cfg accordingly seems correct. > If you want to allow thrid-party pacakges to use the '[test]' extra, you > could have it depend on the corresponding extras (if any) for the > underlying real packages. Yup, in the long run, bit in the short run, I don't want to break packages that depend on "ZODB3 [test]". I released a2 which ads back this extra. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 6, OK: 17
On Sat, Dec 1, 2012 at 8:00 PM, Zope tests summarizer wrote: ... > [1]FAILED winbot / ZODB_dev py_265_win32 >https://mail.zope.org/pipermail/zope-tests/2012-December/069693.html > > > [2]FAILED winbot / ZODB_dev py_265_win64 >https://mail.zope.org/pipermail/zope-tests/2012-December/069694.html > > > [3]FAILED winbot / ZODB_dev py_270_win32 >https://mail.zope.org/pipermail/zope-tests/2012-December/069695.html > > > [4]FAILED winbot / ZODB_dev py_270_win64 >https://mail.zope.org/pipermail/zope-tests/2012-December/069696.html This is due to the release yesterday. I can and will "fix" this, by providing a test extra, but this will only cause no tests to run. The fix may be needed for test of third-party packages that depend on ZODB3 [test]. The winbot needs to be modified to run the tests for persistent, BTrees, ZODB and ZEO separately. > > [5]FAILED winbot / zc.lockfile_py_265_32 >https://mail.zope.org/pipermail/zope-tests/2012-December/069675.html I'll look at this today. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] WebSockets API
On Tue, Nov 27, 2012 at 3:04 AM, Wolfgang Schnerring wrote: ... > I'm not too familiar with WebSocket internals, but one thing that stuck > with me is that you'll need to keep *lots* of open connections, which is > only feasible with an eventloop-based server (which zope.server, for > one, isn't). Actually, it is. zope.server is based on asyncore. Having said that, my impression is that web sockets is largely (or completely) orthogonal to WSGI and the HTTP-based publishing infrastructure. ZTK is only relevant to the extent that it's a bag of useful libraries maintained by the Zope community. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 1, OK: 21
On Wed, Nov 21, 2012 at 8:56 AM, Patrick Gerken wrote: > > > > On Wed, Nov 21, 2012 at 2:00 AM, Zope tests summarizer > wrote: >> >> This is the summary for test reports received on the >> zope-tests list between 2012-11-19 00:00:00 UTC and 2012-11-20 00:00:00 >> UTC: >> >> See the footnotes for test reports of unsuccessful builds. >> >> An up-to date view of the builders is also available in our >> buildbot documentation: >> http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds >> >> Reports received >> >> >>Successful - zopetoolkit_trunk - Build # 82 >>Successful - zopetoolkit_trunk_app - Build # 66 >>Zope-2.10 Python-2.4.6 : Linux >>Zope-2.11 Python-2.4.6 : Linux >>Zope-2.12 Python-2.6.8 : Linux >>Zope-2.13 Python-2.6.8 : Linux >>Zope-2.13 Python-2.7.3 : Linux >>Zope-trunk Python-2.6.8 : Linux >>Zope-trunk Python-2.7.3 : Linux >>winbot / ZODB_dev py_265_win32 >>winbot / ZODB_dev py_265_win64 >>winbot / ZODB_dev py_270_win32 >>winbot / ZODB_dev py_270_win64 >> [1]winbot / zc.lockfile_py_265_32 >>winbot / ztk_10 py_254_win32 >>winbot / ztk_10 py_265_win32 >>winbot / ztk_10 py_265_win64 >>winbot / ztk_11 py_254_win32 >>winbot / ztk_11 py_265_win32 >>winbot / ztk_11 py_265_win64 >>winbot / ztk_11 py_270_win32 >>winbot / ztk_11 py_270_win64 >> >> Non-OK results >> -- >> >> [1]FAILED winbot / zc.lockfile_py_265_32 >> >> https://mail.zope.org/pipermail/zope-tests/2012-November/069449.html > > > Some problem with mandatory file locking on windows. Could be a transient > error. Else somebody might need to get into action on winbot. This is my fault. I updated zc.lockfile to fix a bug and didn't check it on windows. I'll look at this. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 19, OK: 19
On Tue, Sep 4, 2012 at 9:50 AM, Adam GROSZER wrote: > On 09/04/2012 03:43 PM, Tres Seaver wrote: >> >> Who are the developers responsible for maintining the z3c.* packages? >> These failures have been running too long. > > > I'll get to them, I'm just a bit busy. > > >> >> Alex, Jim, you guys have moved zc.buildout out of our normal workflow. I >> think that makes this set of test failures your respondibility. >> > > I can stop the winbot sending those mails or send them to anywhere/anyone > you want. For now, you can send them to me. We have a travis-ci setup, but I think that's only for buildout2 atm. > I personally would care about zc.buildout tests/failures, because it's sorta > basic ZTK/zope infrastructure. Yup. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] [ZODB-Dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
On Tue, Aug 28, 2012 at 12:31 PM, Vincent Pelletier wrote: ... > I forgot in the original mail to mention that NEO does all conflict > resolutions on client side rather than server side. The same happens in > relStorage, but this is different from ZEO. That's good. I'd like to move ZEO in this direction. I'd also like to stop hanging conflict-resolution on classes and have some kind of registry, so that people can set CR policies independent of class implementation. I didn't realize that relstorage did client side CR, but thinking about it, it has to work that way, since there's no relstorage server. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] [ZODB-Dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
On Wed, Aug 29, 2012 at 2:29 AM, Marius Gedminas wrote: > On Tue, Aug 28, 2012 at 06:31:05PM +0200, Vincent Pelletier wrote: >> On Tue, 28 Aug 2012 16:31:20 +0200, >> Martijn Pieters wrote : >> > Anything else different? Did you make any performance comparisons >> > between RelStorage and NEO? >> >> I believe the main difference compared to all other ZODB Storage >> implementation is the finer-grained locking scheme: in all storage >> implementations I know, there is a database-level lock during the >> entire second phase of 2PC, whereas in NEO transactions are serialised >> only when they alter a common set of objects. > > This could be a compelling point. I've seen deadlocks in an app that > tried to use both ZEO and PostgreSQL via the Storm ORM. (The thread > holding the ZEO commit lock was blocked waiting for the PostgreSQL > commit to finish, while the PostgreSQL server was waiting for some other > transaction to either commit or abort -- and that other transaction > couldn't proceed because it was waiting for the ZEO lock.) This sounds like an application/transaction configuration problem. To avoid this sort of deadlock, you need to always commit in a a consistent order. You also need to configure ZEO (or NEO) to time-out transactions that take too long to finish the second phase. I don't think NEO's locking strategy mitigates the deadlock problem much, if at all. The strategy should provide greater transaction throughput and reduce latency. It's a strategy I'd like to implement for ZEO at some point. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] zc.buildout in github foul
On Mon, Aug 20, 2012 at 11:48 AM, Jim Fulton wrote: ... > I also committed a foul by unilaterally moving buildout development to > github. This was originally just a fork for buildout 2, but helpers wanted > to move 1 development there too and, well ... helpers. :) > Anyway, the move of buildout to github wasn't a secret. My foul was even greater than I thought. I didn't change the license (and don't particularly want to except...) and yet I carelessly let a non-zope-contributor become a buildout developer. https://github.com/buildout Honestly, I wasn't even thinking in these terms and should have been. I probably should have truly forked buildout if I wanted to be free from the restriction of having only zope contributors. Maybe I still should. buildout probably shouldn't have been in the zope repo to begin with. It so happens that the one non-zope-contributor is planning to become a zope contributor, we'll soon be in the state that all of the buildout developers are contributors again. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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.buildout semi-resolution
On Mon, Aug 20, 2012 at 11:34 AM, Alex Clark wrote: > Hi, > > > FWIW I spoke with Jim on #buildout this a.m. and he decided to revert my > commit "because people need it". I didn't revert your commit. I just brought back the bootstrap directory (cuz people need it). I endorse the idea of removing trunk, although, in hindsight, we should have given folks a heads up. > I.e. Some folks rely on trunk/bootstrap > existing for their builds. While I don't necessarily agree that's a good > idea, the argument "because people need it" makes 1000x more sense to me > than "Please revert" with no explanation. Or with a legal explanation I > don't understand. I apologize to Jens and Tres if I was stubborn about this, > but I did and still do feel strongly the commit I made was reasonable, and > not reverting it until we could better understand the circumstances was > reasonable too. I guess I missed a discussion. :) My apologies to everyone who was inconvenienced. I gave the OK to clean out the trunk, not thinking a) about the use of trunk/bootstrap, and b) about advising to give folks advance notice. I also committed a foul by unilaterally moving buildout development to github. This was originally just a fork for buildout 2, but helpers wanted to move 1 development there too and, well ... helpers. :) Anyway, the move of buildout to github wasn't a secret. > To clear up any remaining confusion: > > - In the Plone community, it is quite common to make this type of change to > indicate active development takes place somewhere else. This is common (for some definition of common) practice in the Zope community as well. We did it when we moved the Zope repo from CVS to svn. The CVS repo is still around: http://cvs.zope.org/ :) > We leave tags (and > branches) in place in case people need them. I did not remove, or move the > zc.buildout project, nor did I intend to disrupt development in any way. I > simply wanted to "leave a message" on behalf of the work Jim and Domen were > doing. Yup. > - Personally, I use an extension called "buildout.bootstrap" to always > download the latest bootstrap.py file. That would have been a good time to realize that there might be more widespread breakage and revert the deletion or bring back the buildout directory. > Removing trunk broke my builds, at > which point I cut a new release of buildout.bootstrap containing the new > URL: > > >- http://pypi.python.org/pypi/buildout.bootstrap/1.4.2 Well, hopefully, all's well now. Thanks for helping. (really) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] We need to change how code ownership works.
On Mon, Aug 20, 2012 at 6:39 AM, Charlie Clark wrote: ... > Again, as Jens has repeatedly said we should not conflate the separate items > of toolchain and service provider. +1 > Zope Foundation has hardware and a proven > track record in hosting. Is anyone actually criticising this? FTR, in the case of svn.zope.org, it's ZC hardware and hosting with a lot of much appreciated help from Jens. We're doing a pretty ok job (if you ignore a near catastrophe) in providing what is, by today's standards, a bare-bones service. User management is awkward. We lack any automated support for review, and a number of other services provides by github and bitbucket. svn.zope.org doesn't take much of my time most of the time, but it's still a potential (and occasional real) time suck for me that I'd love to jettison. Life is short, why do this ourselves when there are excellent services available? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] We need to change how code ownership works.
On Sun, Aug 19, 2012 at 7:01 AM, Lennart Regebro wrote: > On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl wrote: >> >> On Aug 19, 2012, at 10:17 , Lennart Regebro wrote: >> >>>> And since it becomes ever easier to accept code from unknown sources (e.g. >>>> pull requests) legal code ownership becomes an issue again. >>> >>> And that returns me to my first question: Is it really legally >>> different for a contributor to accept a pull request from a >>> non-contributor compared with a contributor merging a patch from a >>> non-contributor? >> >> Legally, both are disallowed unless there's some proof (written statement >> etc) from the code author that he assigns ownership of the patch or the >> contents of that pull request to the contributor who is doing the checkin. >> >> In the past we haven't done a good job of enforcing this clear ownership >> assignment chain. There are always code patches from non-contributors in the >> bug tracker that may make it into the code base with the help of a >> contributor. There's a grey area: Is the act of submitting a patch into the >> Zope bug tracker enough to signal "I am giving you ownership of this code"? >> I am not sure. >> >> GitHub makes this pulling in of "outside" code even easier. I'm afraid it >> will become even harder to really maintain this chain of custody. > > This is then, IMO a problem that we should fix. What you are in fact > saying is that the current system are violating people's copyright > everytime we merge a non-contributors patch. It is unfeasible to not > merge peoples patches, and I think it is also a big problem that the > way the ownership of the code works now inhibits the increased > simplicity of making and merging fixes for non-core contributors. > > In other words, we have had an ownership situation which is terrible, > and nobody seems to have realized this until now. Well, now we know. > > As such, the discussion must now shift from "don't do this" to "how do > we do this". Poeple want to contribute and we should not say "don't do > that", we have to figure out *how* to make it possible to do that, and > pretty pronto as well. IANAL and I'm not even very interested in this discussion, however, I thought I should point out how the pylons project handles this. (Apologies, of someone beat me to it and I didn't see it) I think their solution is rather ingenious. IIUC, their repositories have CONTRIBUTORS.txt files: https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt Committing your name to this file constitutes signing the contributor's agreement. A pull request from a new contributor would presumably have to contain an update to this file. Because pull requests are not just patches but retain commit history, there is a record that a person with a github (or bitbucket, my current preference) account made the update. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] PW reset failing on zope.org
On Thu, Aug 16, 2012 at 11:43 PM, Alan Runyan wrote: > Attempted to reset password on zope.org and got an error. > Can someone help out? If this is so you can upload new ssh keys, go to: https://svn.zope.org/manage-profile/ See http://docs.zope.org/developer/becoming-a-committer.html#deposit-ssh-pubkey Otherwise, I didn't think the new zope.org site allowed logins. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] ssh access to svn.zope.org not working
On Mon, Jun 25, 2012 at 7:50 AM, Maurits van Rees wrote: > Hi, > > I can access svn.zope.org over normal http just fine, but svn+ssh does not > work for me today. This has worked fine until last week. > > $ svn ls svn+ssh://svn.zope.org/repos/main/zopetoolkit/doc > svn: E170001: Unable to connect to a repository at URL > 'svn+ssh://svn.zope.org/repos/main/zopetoolkit/doc' > svn: E170001: Could not create SASL context: generic failure: No such file > or directory > > That is with subversion 1.7. I tried 1.6 too, but this just says "svn: > generic failure". > > This is with the ssh key that I use for userid mauritsvanrees. I did not > change anything in my setup recently that I remember. > > Anyone else having problems with this? Works fine for me: jim@sb14:~$ svn ls svn+ssh://svn.zope.org/repos/main/zopetoolkit/doc Makefile bootstrap.py buildout.cfg scripts/ source/ src/ jim@sb14:~$ svn --version svn, version 1.6.6 (r40053) compiled Jun 5 2011, 14:51:47 ... -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 7, OK: 38
On Sun, Jun 24, 2012 at 10:27 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/24/2012 09:00 PM, Zope tests summarizer wrote: >> [1] FAILED Repository policy check found errors in 273 projects >> https://mail.zope.org/pipermail/zope-tests/2012-June/064767.html > > I think I got nearly all the ZTK pacakge branches finally clean here: > the exceptions are > > - - zope.app.twisted pulls in TwistedCore 2.0.5 as an external from the > twisted SVN server > > - - zope.html includes non-ZPL code (the ckeditor code). > > I think it would be preferable to replace the svn:externals bit in > zope.app.twisted with a download of an eg:: however, twiseted 2.0.5 > fails to install cleanly under setuptools / buildout, which likely means > a custom recipe. :( As for the ckeditor bits: they may actually be in > violation of our policy for checking in code not owned by the > contributor. :( Can somebody who uses / depends on zope.html comment? > Maybe we wuold be better off pulling in the code from a CDN? My recollection is that zope.app.twisted included Twisted because, at the time, Twisted wasn't installable by setuptools. This changed a long time ago. zope.app.twisted should just stop trying to include Twisted. In the unlikely event that it doesn't work with current versions of Twisted, it should simply be fixed or removed from the ZTK. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ 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] RFC: drop interactive feature of zdaemon
I (and many people I know) find the interactive feature of zdaemon annoying. I'd like to drop it, both to reduce annoyance and to reduce the amount of code to maintain. Any objections? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://www.dublinstore.com/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface 4.0.0 considered annoying.
On Sun, May 20, 2012 at 4:28 PM, Lennart Regebro wrote: > On Sun, May 20, 2012 at 6:08 AM, Tres Seaver wrote: >> I will release a 4.0.1 silencing the warnings unless somebody speaks up >> in their favor. > > We should make sure we have 2to3 fixers for everything change as well. > I added some fixers, but it's so long ago I'm not sure all changes are > covered. But with fixers the warnings aren't very problematic, as > fixing the loud failures is just a matter of running the fixers. Except that most of us aren't going to use 2to3, except for an initial stab at porting to 2&3. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://www.dublinstore.com/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface 4.0.0 considered annoying.
On Sun, May 20, 2012 at 12:08 AM, Tres Seaver wrote: > On 05/19/2012 07:23 PM, Jim Fulton wrote: ... >> I'd forgotten the fail silently bit. Can't we make the fail loudly >> for Python 3? > > They already do: 4.0.0 makes them exceptions under Python3: that fact > was actually my rationale for the warnings under Python2, to allow folks > to find and remediate them before porting. That's reasonable. I'd probably have had the same inclination -- until I experienced the result. :) > I will release a 4.0.1 silencing the warnings unless somebody speaks up > in their favor. Thanks. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://www.dublinstore.com/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface 4.0.0 considered annoying.
On Sat, May 19, 2012 at 5:59 PM, Tres Seaver wrote: > On 05/19/2012 12:12 PM, Jim Fulton wrote: >> The declaration-syntax warnings in the zope.interface 4.0.0 are >> annoying and mostly pointless. >> >> There will be enough pain in porting applications to Python 3, >> avoiding the surprise of having to use a different >> interface-declaration syntax will not be of any consequence. >> >> While the deprecation warning may provide some tiny benefit, the >> annoyance, especially for applications or libraries that still support >> Python 2.5 far outweights the benefit. > > We're in an odd spot: the Python3 support for zope.interface mostly > works, but the class advice bits (implements, implementsOnly, > classProvides) fail silently under Python3 before 4.0.0: they literally > have no effect due to changes in class initialization machinery. > zope.interface 4.0.0 changes those silent failures into exceptions (which > is what I thought you were going to complain about). I'd forgotten the fail silently bit. Can't we make the fail loudly for Python 3? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://www.dublinstore.com/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.interface 4.0.0 considered annoying.
The declaration-syntax warnings in the zope.interface 4.0.0 are annoying and mostly pointless. There will be enough pain in porting applications to Python 3, avoiding the surprise of having to use a different interface-declaration syntax will not be of any consequence. While the deprecation warning may provide some tiny benefit, the annoyance, especially for applications or libraries that still support Python 2.5 far outweights the benefit. I propose that these deprecation warnings be removed. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://www.dublinstore.com/ ___ 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] Python 3.3 port of zope.configuration
On Thu, Apr 12, 2012 at 7:37 PM, Tres Seaver wrote: ... > How deep is the six dependency? For every package I've ported to date, > it has ended up being more sensible to implement a local '_compat' module > which had only the needed straddles (sometimes inspired by six, sometimes > very localized). I can see why this might be sensible in the small, or for packages that really have to minimize dependencies (like buildout), but in the large, this sounds like a huge DRY violation. If we all adopt a 2&3 strategy, then six should be a given and not even count as a dependency. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://www.dublinstore.com/ ___ 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] Adding broken/missing support to zope.interface?
On Mon, Apr 9, 2012 at 4:33 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/09/2012 04:15 PM, Martin Aspeli wrote: >> On 9 April 2012 15:41, Brian Sutherland >> wrote: >> >>> On Sun, Apr 08, 2012 at 01:04:37PM -0700, Ross Patterson wrote: >>>> experimental.broken is working well for me. It greatly aided me >>>> in getting through a particularly nasty upgrade allowing me to >>>> cleanup the ZCA cruft left by poorly behaved add-ons. I'd like >>>> to proceed with adding the core of this to zope.interface and I >>>> need the developers/maintainers to weigh in. >>>> >>>> The first and most fundamental matter is changing interface >>>> pickles such that they can be unpickled into something that can >>>> fulfill the minimum interface contract and don't break the ZCA. To >>>> that end, I'd like to add the following to >>>> zope.interface.interface: >>>> >>>> ... try: from ZODB.broken import find_global from ZODB.broken >>>> import IBroken def find_interface(modulename, globalname, >>>> Broken=IBroken, type=InterfaceClass): """ Find a global >>>> interface, returning a broken interface if it >>> can't be found. >>>> """ return find_global(modulename, globalname, Broken=IBroken, >>>> type=InterfaceClass) except ImportError: IBroken = Interface def >>>> find_interface(modulename, globalname, Broken=IBroken, >>>> type=InterfaceClass): """ Find a global interface, raising >>>> ImportError if it can't be >>> found. >>>> """ # From pickle.Unpickler.find_class __import__(module) mod = >>>> sys.modules[module] klass = getattr(mod, name) return klass ... >>>> class InterfaceClass(Element, InterfaceBase, Specification): ... >>>> def __reduce__(self): if self is IBroken: return self.__name__ >>>> return (find_interface, (modulename, globalname)) ... >>> >>> -1 > > Agreeed. I'm more like -20 on this implementation, but +1 on the goal. > >>> >>> For a number of reasons, but mainly because you add a test >>> dependency on the ZODB from zope.interface. I think that >>> zope.interface is such a fundamental package and the dependency is >>> unacceptable. >>> >> >> It's a soft dependency only, looking at the code sample. >> >> >>> There has lately been a LOT of work done reducing the dependency >>> structure of zope.* packages. You need a VERY good reason to start >>> reversing that. >> >> >> It doesn't add any more (required) dependencies. > > - -1 on any dependency, soft or hard, from zope.interface -> ZODB > >> This is a real issue that is breaking the sites of a lot of real >> users of zope.interface in a way that is hard to debug and reverse. >> >> Can you think of a better way to get around it? Other than "don't get >> into the situation" which isn't a valid answer as long as the ZTK >> ecosystem supports persistent local components. > > Persistent component registries are not a good enough reason to add such > coupling (I'd be in favor of splitting support for persistent registries > out of zope.component, too, while we're at it). > > Let's put the "broken" support into code which depends on > zope.interface, zope.component, and the ZODB, and invert the dependency > by having the new code install something into the base code which > provides the desired support: the only change to zope.interface should > be documenting the insertion point, and testing that it does the right > thing when a dummy is plugged into it. +1 Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://www.dublinstore.com/ ___ 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] Merge proposal: zope.interface/branches/tseaver-no_2to3
On Thu, Apr 5, 2012 at 4:36 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Having merged the 'tseaver-better_unittests' branch to the zope.interface > trunk last Friday, I now have a new branch ready for merging: > > http://svn.zope.org/zope.interface/branches/tseaver-no_2to3 > > The branch excises the use of the 'lib2to3' module and associated fixers > in favor of a "compatible subset" which supports Python 2.6, 2.7, 3.2, > and PyPy 1.8. At this point all tests pass under all four environments > using 'python setup.py test' as well as using 'nosetests.' Code coverage > is at 99.9% (two edge-case lines are untested). > > The biggest advantage of the subset approach is that installing the > package now takes on the order of seconds (2 seconds on my machine) > rather than minutes (2 minutes my machine). Running the tests is also > much faster. The secondary win is that running the same code under Py3k > makes for better support / bug reports (line numbers match, etc.) > > Unless the community's consensus is against the branch, I plan to merge > it to the zope.interface trunk by early next week. Woo hoo! Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Bad ZODB 3.10.5 egg on PyPI, cleanup needed
On Mon, Mar 12, 2012 at 6:13 PM, Hanno Schlichting wrote: > On Mon, Mar 12, 2012 at 10:55 PM, Marius Gedminas wrote: >> http://pypi.python.org/pypi/ZODB3/3.10.5 contains various proper win32 >> eggs in addition to that .win32.zip. The PyPI page for 3.10.4 did not >> have any weird .win32.zip files. >> >> Can someone please remove that "dumb" binary file which is "built for >> Windows XP" (and doesn't even mention for which Python version)? > > J1m apparently took care of that: > > add 2.7 file ZODB3-3.10.5.win32.zip 2012-03-12 20:22 J1m > 12.x.x.x > remove file ZODB3-3.10.5.win32.zip 2012-03-12 22:06 J1m > 12.x.x.x Sorry about that. This wasn't a bad distribution, but a fail on setuptools part afaict. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] how to add SOAP APIs in zope 3
On Mon, Jan 30, 2012 at 6:26 AM, Sanjay Rao wrote: ... > If anybody can give some pointers, it would be greatly appreciated. I recommend using an established SOAP server. You should be able to use application code that works with Zope3/ZTK/whatever with any server framework. If not, then you have another problem. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.wsgi.paste doesn't emit a ProcessStarting event
On Thu, Jan 19, 2012 at 8:56 AM, Marius Gedminas wrote: > On Thu, Jan 19, 2012 at 06:30:35AM -0500, Jim Fulton wrote: .. >> I'll also release this change as zope.app.wsgi 3.15.0, or do you think >> this should be 4.0.0? > > 3.15.0 sounds about right to me. Done. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.wsgi.paste doesn't emit a ProcessStarting event
On Wed, Jan 18, 2012 at 6:50 PM, Marius Gedminas wrote: > On Wed, Jan 18, 2012 at 05:00:27PM -0500, Jim Fulton wrote: >> zope.app.server emits a ProcessStarting event on startup. >> >> zope.app.wsgi.paste doesn't. I think it should. > > +1 > >> If there are no >> objections, I'll make a bug fix release for this. > > Hm. I've an app that wraps zope.app.wsgi like this: > >from zope.app.wsgi import getWSGIApplication >from zope.app.appsetup.interfaces import ProcessStarting >from zope.event import notify > >def app_factory(global_config, **local_conf): >"""Create a Zope WSGI application given a zope configuration. ... >""" >app = getWSGIApplication(StringIO(local_conf['config'])) >notify(ProcessStarting()) >return app > > Would this result in duplicate ProcessStarting() events after your proposed > change? Yes. > Can duplicate ProcessStarting() events cause harm? I don't know. Theoretically. > If so, I'd rather > see a bigger version bump than just a bugfix. Ideally, but ... > (We are pinning all our dependency versions with buildout-versions, so our app > won't break if you rele--oh, I see you already released 3.9.3zc2 with the > change.) Yup, yup. > >> BTW, I ended up making a 3.9.3zc1 release (this will spur 3.9.3zc2 >> release) because the latest release breaks our apps' tests. Not sure >> if this was due to zope.testbrowser 4, or the (until recently) >> unreleased zope.app.testing changes needed to work with >> zope.testbrowser 4. I haven't had time to chase these down, thus the >> 3.9.3zc1 release, which I'm not terribly proud of. > > I'm confused about this. "Latest release" refers to what, 3.9.3? or was > there > a newer version that is now hidden on PyPI? Sorry, my bad. I forgot to unhide 3.14.0 (and hide 3.9.3zc2). Michael Howitz fixed that. Thanks Michael. Your argument about the duplicate events is a reasonable one. I considered it, but thought that either people weren't using zope.app.wsgi.paste or didn't care about the event, given how long the problem has existed. I could reverese the change with a 3.9.3zc3 release. That would force me into trying to figure out the breakages introduced by "later" releases, or fork or monkey patch zope.app.wsgi. I'd rather not. :) Given that an unpinned fetch of zope.app.wsgi won't get 3.9.3zc2 I'm thinking that my small foul is unlikely to do harm. I'll also release this change as zope.app.wsgi 3.15.0, or do you think this should be 4.0.0? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.app.wsgi.paste doesn't emit a ProcessStarting event
zope.app.server emits a ProcessStarting event on startup. zope.app.wsgi.paste doesn't. I think it should. If there are no objections, I'll make a bug fix release for this. BTW, I ended up making a 3.9.3zc1 release (this will spur 3.9.3zc2 release) because the latest release breaks our apps' tests. Not sure if this was due to zope.testbrowser 4, or the (until recently) unreleased zope.app.testing changes needed to work with zope.testbrowser 4. I haven't had time to chase these down, thus the 3.9.3zc1 release, which I'm not terribly proud of. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] bugifx release for zope.error
Done. Jim On Tue, Jan 17, 2012 at 3:17 PM, Jan-Wijbrand Kolman wrote: > Hi, > > I'd like to make a bugfix release for zope.error. Could someone grant me the > needed permissions on pypi for this? My pypi handle is "jw". > > Thank you in advance. > > regards, jw > > ___ > 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 ) -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC ZTK: Change zope.app.wsgi to set REMOTE_USER
Committed and released as 3.14.0. Jim On Mon, Jan 9, 2012 at 6:26 PM, Jim Fulton wrote: > I'm trying to untangle zope.app-based applications from zope.server > and am trying to figure out a sane way to get an access log. > > zope.app.wsgi sets the "wsgi.logging_info" WSGI environment variable > with a user label to display in access logs (presumably). The only > thing I've seen that leverages this is (perversely) > zc.zopeservertracelog, which bridges this mechanism with the > access-log mechanism provided by zope.server. Does anyone know of > anything else that uses wsgi.logging_info? > > I'd like to use something independent of the server, like > paste.translogger. paste.translogger get the user from the > REMOTE_USER environment variable. > > I propose to modify zope.app.wsgi to set REMOTE_USER if it isn't > already set. This would be in addition to setting wsgi.logging_info. > > Any objections? > > Jim > > -- > Jim Fulton > http://www.linkedin.com/in/jimfulton -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC ZTK: Change zope.app.wsgi to set REMOTE_USER
On Mon, Jan 9, 2012 at 6:26 PM, Jim Fulton wrote: > I'm trying to untangle zope.app-based applications from zope.server > and am trying to figure out a sane way to get an access log. > > zope.app.wsgi sets the "wsgi.logging_info" WSGI environment variable > with a user label to display in access logs (presumably). The only > thing I've seen that leverages this is (perversely) > zc.zopeservertracelog, which bridges this mechanism with the > access-log mechanism provided by zope.server. Does anyone know of > anything else that uses wsgi.logging_info? > > I'd like to use something independent of the server, like > paste.translogger. paste.translogger get the user from the > REMOTE_USER environment variable. > > I propose to modify zope.app.wsgi to set REMOTE_USER if it isn't > already set. This would be in addition to setting wsgi.logging_info. > > Any objections? BTW, zope.app.wsgi isn't in the ZTK. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC ZTK: Change zope.app.wsgi to set REMOTE_USER
I'm trying to untangle zope.app-based applications from zope.server and am trying to figure out a sane way to get an access log. zope.app.wsgi sets the "wsgi.logging_info" WSGI environment variable with a user label to display in access logs (presumably). The only thing I've seen that leverages this is (perversely) zc.zopeservertracelog, which bridges this mechanism with the access-log mechanism provided by zope.server. Does anyone know of anything else that uses wsgi.logging_info? I'd like to use something independent of the server, like paste.translogger. paste.translogger get the user from the REMOTE_USER environment variable. I propose to modify zope.app.wsgi to set REMOTE_USER if it isn't already set. This would be in addition to setting wsgi.logging_info. Any objections? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 6, OK: 34, UNKNOWN: 6
On Mon, Dec 26, 2011 at 6:50 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/25/2011 08:00 PM, Zope tests summarizer wrote: >> [6] UNKNOWN UNKNOWN : Zope-2.12 Python-2.6.6 : Linux >> https://mail.zope.org/pipermail/zope-tests/2011-December/054832.html >> >> >> [7] UNKNOWN UNKNOWN : Zope-2.12-alltests Python-2.6.6 : Linux >> https://mail.zope.org/pipermail/zope-tests/2011-December/054833.html >> >> >> [8] UNKNOWN UNKNOWN : Zope-2.13 Python-2.6.6 : Linux >> https://mail.zope.org/pipermail/zope-tests/2011-December/054834.html >> >> >> [9] UNKNOWN UNKNOWN : Zope-2.13-alltests Python-2.6.6 : Linux >> https://mail.zope.org/pipermail/zope-tests/2011-December/054835.html >> >> >> [10] UNKNOWN UNKNOWN : Zope-trunk Python-2.6.6 : Linux >> https://mail.zope.org/pipermail/zope-tests/2011-December/054836.html >> >> >> [11] UNKNOWN UNKNOWN : Zope-trunk-alltests Python-2.6.6 : Linux >> https://mail.zope.org/pipermail/zope-tests/2011-December/054837.html > > > > All apparently network failures during bootstrap. Dude, you're a trooper for looking at these. I wonder if failed builds could be retried. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.server still used?
On Tue, Dec 20, 2011 at 2:12 AM, Chris Withers wrote: > On 20/12/2011 07:08, Wolfgang Schnerring wrote: >> >> as advanced as we've come to know. What do people use here, what are >> your experiences and ideas? > > > What's wrong with mod_wsgi? Debugging with it seems to be a pain, so you end up using different servers in development and production. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.paste
On Thu, Dec 15, 2011 at 2:00 PM, Stephan Richter
wrote:
> On Thursday, December 15, 2011 01:54:01 PM Jim Fulton wrote:
>> How do values get from DEFAULT into the other sections?
>>
>> If this is a buildout behavior, it's unintentional and unlikely to
>> work in the future.
>
> This is a configparser feature. The [DEFAULT] section contains options that
> propagate to all other sections. Unless buildout is not using configparser in
> the future, then the feature is pretty stable. :-)
buildout 2 doesn't use config parser. IIRC, there was never an
intention to support DEFAULT (except perhaps beyond some initial
prototypes).
> Of course, it is no big
> deal to repeat the options in every section, but that's more verbose.
You could use macros,
http://pypi.python.org/pypi/zc.buildout/1.5.2#extending-sections-macros
[dev_ini]
recipe = collective.recipe.template
call-server = http://localhost:8000/calls/tropo
input = ${buildout:paster-directory}/dev.ini.in
output = ${buildout:paster-directory}/dev.ini
sites-config-directory = ${buildout:directory}/data/sites-config/dev
mail-directory = ${buildout:var-directory}/mail
zodb-config-path = ${buildout:paster-directory}/zodb.conf
database = db
database-host = localhost
logs-directory = ${buildout:directory}/logs
web-server-host = localhost
web-server-port = 8000
[staging_ini]
<= dev
input = ${buildout:paster-directory}/prod.ini.in
output = ${buildout:paster-directory}/staging.ini
web-server-host = staging
web-server-port = 8020
database = staging-db
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.paste
On Thu, Dec 15, 2011 at 1:41 PM, Stephan Richter
wrote:
> On Thursday, December 15, 2011 12:59:57 PM Jim Fulton wrote:
>> So, does anyone know of a recipe, similar to zc.zope3recipes:instance
>> that drives this?
>
> I am using collective.recipe.template to generate different configuration
> files
> from a common template. Here is a snippet from my buildout file:
>
> [DEFAULT]
> input = ${buildout:paster-directory}/dev.ini.in
> output = ${buildout:paster-directory}/dev.ini
> sites-config-directory = ${buildout:directory}/data/sites-config/dev
> mail-directory = ${buildout:var-directory}/mail
> zodb-config-path = ${buildout:paster-directory}/zodb.conf
> database = db
> database-host = localhost
> logs-directory = ${buildout:directory}/logs
> web-server-host = localhost
> web-server-port = 8000
>
> [dev_ini]
> recipe = collective.recipe.template
> call-server = http://localhost:8000/calls/tropo
>
> [staging_ini]
> recipe = collective.recipe.template
> input = ${buildout:paster-directory}/prod.ini.in
> output = ${buildout:paster-directory}/staging.ini
> web-server-host = staging
> web-server-port = 8020
> database = staging-db
How do values get from DEFAULT into the other sections?
If this is a buildout behavior, it's unintentional and unlikely to
work in the future.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.paste
On Thu, Dec 15, 2011 at 12:53 PM, Jim Fulton wrote: > On Thu, Dec 15, 2011 at 12:22 PM, David Glick > wrote: >> On 12/15/11 9:15 AM, Jim Fulton wrote: >>> >>> I'm going to take the liberty of creating a new package in the >>> zope.app namespace. >>> >>> It's a small package that allows, zope.app-based applications to be wired >>> up to >>> WSGI middleware and servers using the paste-deploy framework. >>> >>> (Hopefully, I didn't miss something that already does this. I'm not sure >>> where >>> I would look for such a thing.) >>> >>> If anyone objects (or if this is duplicating something that already >>> exists), >>> please let me know. >>> >> There is http://pypi.python.org/pypi/zope.app.wsgi > > Doh! I didn't realize that that provides paste integration. > > Cool. Thanks. So, does anyone know of a recipe, similar to zc.zope3recipes:instance that drives this? If not, I'll add support to zc.zope3recipes. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.paste
On Thu, Dec 15, 2011 at 12:22 PM, David Glick wrote: > On 12/15/11 9:15 AM, Jim Fulton wrote: >> >> I'm going to take the liberty of creating a new package in the >> zope.app namespace. >> >> It's a small package that allows, zope.app-based applications to be wired >> up to >> WSGI middleware and servers using the paste-deploy framework. >> >> (Hopefully, I didn't miss something that already does this. I'm not sure >> where >> I would look for such a thing.) >> >> If anyone objects (or if this is duplicating something that already >> exists), >> please let me know. >> > There is http://pypi.python.org/pypi/zope.app.wsgi Doh! I didn't realize that that provides paste integration. Cool. Thanks. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.app.paste
I'm going to take the liberty of creating a new package in the zope.app namespace. It's a small package that allows, zope.app-based applications to be wired up to WSGI middleware and servers using the paste-deploy framework. (Hopefully, I didn't miss something that already does this. I'm not sure where I would look for such a thing.) If anyone objects (or if this is duplicating something that already exists), please let me know. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC: Removing InterfaceClass.deferred
On Thu, Dec 8, 2011 at 3:44 PM, Tres Seaver wrote: > I can't find any use of it outside of tests, there are no docs for it, > and Jim doesn't remember why it is there. Any objections to removing it > on the trunk? +1 Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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.buildout 2.0.0a1 for py33...
On Thu, Dec 8, 2011 at 2:32 AM, Chris McDonough wrote: > Could someone copy the existing zc.buildout-2.0.0a1-py3.2.egg file over > to zc.buildout-2.0.0a1-py3.3.egg on PyPI so it gets shlepped down when > we try to use the Python trunk against existing buildouts? Not sure how to do that, but I copied the egg on my computer and uploaded it. I had to lie about the Python version. If that doesn't work, I can add you as a project maintainer, but Tres is already one. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.locales pypi access
On Tue, Dec 6, 2011 at 4:38 PM, Jan-Jaap Driessen wrote: > Hi, > > I'd like to make a minor release of zope.app.locales. Could anyone > grant access to handle "janjaapdriessen"? Done. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On Thu, Nov 17, 2011 at 7:25 AM, Laurence Rowe wrote: ... (Interesting roadmap snipped) > This process will necessitate a lot of merging, so I want to propose > that we move to Git for development (something we found very helpful > at our recent San Francisco Zope 4 sprint.) I don't have any opinion > on where the canonical repository should be hosted - I know some > people have strong opinions that this should be on Zope Foundation > controlled hardware. If that's to be the case then we will need the > svn.zope.org maintainers to setup a shared git repository on that > machine. Why on that machine? Why not have the ZF set up git.zope.org? As the primary maintainer of svn.zope.org, I'm not volunteering to have more stuff there. :) > I think mirroring to github (and/or launchpad in future) will > be the simplest way to provide an anonymously accessible and web > browsable copy. I haven't used GitHub myself, but I gather it's good. :) Why not just let them host the project? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.schema and Python 3
On Mon, Nov 7, 2011 at 1:09 PM, Brian Sutherland wrote: > On Fri, Oct 14, 2011 at 12:52:00PM +0200, Brian Sutherland wrote: >> On Mon, Oct 10, 2011 at 01:14:26PM +0200, Brian Sutherland wrote: >> > I've managed to port zope.schema to Python 3.2 on a branch >> > (jinty-python3). >> > >> > It gives up Python 2.5 compatibility and depends on six >> > (http://packages.python.org/six/). Any objections to me merging this >> > branch? >> >> I just merged this to trunk. > > Thanks to some great work by Tres, it looks like the buildbots are green > and this change is bedded down. > > Could someone release zope.schema trunk? > > (or give me rights to do so, jinty on pypi) I empowered you! :) Thanks. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] ZEO client cache not working properly with beforestorage
On Mon, Nov 7, 2011 at 3:41 AM, Malthe Borch wrote: > On 25 October 2011 17:53, Malthe Borch wrote: >> I'll try and see if I can understand what might be the right thing to >> expect and write a test case for that. > > Following up here on the list to get some feedback on the patch I > submitted concerning this issue: > > https://bugs.launchpad.net/zodb/+bug/881493 > > The patch includes a test case and necessary code modifications. > > If someone could review the test case included in the patch, I'd appreciate > it. Thanks. I'll review it. Not sure when :), but I'll definitely put this on my to-do list for 3.11. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 - San Francisco sprint and beyond
On Sun, Nov 6, 2011 at 7:56 PM, Hanno Schlichting wrote: > Hi. > > A couple of us came together before the Plone conference to work on > various Zope related topics. We worked on the following areas: This sounds like it was a very productive sprint. Thanks for the update. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testrunner and nose count doctests differently
On Thu, Nov 3, 2011 at 5:14 AM, Chris Withers wrote: > Hi Michael, > > On 03/11/2011 09:12, Michael Howitz wrote: >> Run both test runners with the option -vv to see which tests are run. >> (I did this for your code and the list of tests seems to be equal.) It would be interesting for the rest of us to know the length of that list. > > Cool, I'd done this already, but it's good to have someone else verify > this :-) > >> Though this is no answer to the question which code does the counting. > > Indeed, so I guess that becomes the real question! My guess is that when you're using the zope testruner, you're somehow picking up zope.testing.doctest, which counts each doctest example as a test. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 4?
I saw Zope 4 mentioned in public today. This is the first time I'd seen it mentioned in public. Is there a more formal announcement anywhere? Is there a description of what it is envisioned to be? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] ZEO client cache not working properly with beforestorage
I take issue with "not working properly". Before storage works correctly with ZEO. On Tue, Oct 25, 2011 at 5:43 AM, Malthe Borch wrote: > If I set my beforestorage to a reasonably current time, e.g. "now", I > expect to get reasonably good performance from a ZEO client cache. > > Instead, I find that beforestorage: > > 1) asks the cache to ``loadBefore``; This is absolutely the right thing to do. > 2) but that method only looks for "noncurrent" entries; > 3) meanwhile, my cache only has "current" records. > > I'm not sure if the problem is that the cache shouldn't be setting the > loaded oids as "current", or if the ``loadBefore`` method should also > accept (some) "current" entries. I agree that the ZEO cache implementation should check for current records with tids < the before time. This has potential implications beyond beforestorage. Would you mind creating an issue: https://bugs.launchpad.net/zodb/+filebug Of course, patches including tests are appreciated. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Conversion old.zope.org to static site
On Fri, Oct 14, 2011 at 10:12 AM, Tom Gross wrote: > Hi > > Congrats from me too! > > What's the procedure of applying for commiter status at the zope.org > repository now? The documentation at [1] states to request a user > account at old.zope.org. If it is a static site there are no user > accounts, right? > > I'm in the process of applying for commiter status but already stuck at > the first level :( We're working on a replacement process. We have a system in place, but we're having some JS-related performance issues we're sorting out. We'll instructions as soon as we have things sorted out. For now, you can send me a note to request an account. You'll then get emailed a link to let you enter your password. That will get you to the next stage. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Thu, Sep 1, 2011 at 1:28 PM, Chris McDonough wrote:
> On Thu, 2011-09-01 at 09:22 -0400, Jim Fulton wrote:
>> On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough wrote:
>> ...
>> > - zope.testing (for addCleanUp of the global registry in
>> > z.c.globalregistry and other places)
>>
>> This particular detail should simply be cleaned up by
>> moving these calls into tests module.
>
> This is in zope.component.globalregistry at module scope:
>
> base = BaseGlobalComponents('base')
>
> try:
> from zope.testing.cleanup import addCleanUp
> except ImportError:
> pass
> else:
> addCleanUp(lambda: base.__init__('base'))
> del addCleanUp
>
> I didn't see that the registration was conditional on the presence of
> zope.testing last night, but if I understand the intent correctly, it's
> to ensure that importing z.component at all will add a cleanup callback
> to zope.testing such that z.testing.cleanUp() will wipe the global
> registry state. Lots of existing tests will break if this isn't done,
> so I'm not sure that moving it into a place where it isn't executed as a
> side effect is feasible?
I was thinking only of zope.component's tests. There's still the issue of
tests of clients of zope.component, which my suggestion doesn't address.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough wrote: ... > - zope.testing (for addCleanUp of the global registry in > z.c.globalregistry and other places) This particular detail should simply be cleaned up by moving these calls into tests module. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Tue, Aug 30, 2011 at 2:23 AM, Wolfgang Schnerring wrote: > * Jim Fulton [2011-08-26 07:35]: >> On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring wrote: >> > * Jim Fulton [2011-08-25 15:24]: >> > > stripping zope.component to its core would be backwards incompatible now. >> > >> > Why? zope.component already uses extras_require to signify the various >> > integration parts: [persistentregistry,security,zcml]. >> >> But it still contains code to go with those dependencies. To clean >> this up, you'd have to remove that code, which would cause breakage. > > I have the feeling I'm missing or overlooking something. Could you > help me find it? These are the two scenarios, as I understand them: > > a) zope.component declares an extras_require "foo", making it depend > on zope.foo, and also has a module zope.component.foo with integration > code in it. > > b) zope.component declares an extras_require "foo", making it depend > on zope.foo *and* a new package zope.component_foo (which contains the > extracted integration code). Also, zope.component has BBB imports in > zope.component.foo that point to zope.component_foo. So in b, you'd move the integration code to a separate package that becomes part of the extras. > > My understanding is that from a client's perspective these two are > equivalent: if you want the foo functionality for zope.component, you > have to depend on zope.component[foo], and you import stuff from > zope.component.foo. Except that probably many (most?) clients of zope.component don't bother to name the extras because they depend on the other dependencies anyway, for other reasons. I don't have any data to back this up, but it might be useful to look at something like Blue Bream to see if the packages in it that depend on zope.component include the extras. I'd bet $.05 that they don't. You're right though that if projects that use zope.component are careful to use extras accurately, then the integration code could be moved out as long as the extras themselves are retained (and enhanced). You could even argue that clients that don't declare needed extras are broken and deserve to lose. Note that I added the extras in desperation several years ago as I was preparing to teach a PyCon zope.component tutorial and was horrified to discover that depending on zope.component would bring in most of Zope 3. I was hoping to make the point that zope.component could be used outside of Zope. Ironically, most or all of the students were Zope users anyway, so my point was largely moot. :/ It could have been argued at the time that adding the extras was a backward-incompatible change, but I don't think it effected anyone. At least I never heard that it did, which supports my assumption that people are already depending on the dependencies named in the extras and aren't bothering to name them. ... >> IMO, what's core is a way to plug in component registries, not a >> particular strategy for component registries. > > Do I understand you correctly that the fact that getSiteManager is > "hookable" should be core, but the thread-local mechanism of setSite() > should not? That seems like a very useful delimination. Yes. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring wrote: > * Jim Fulton [2011-08-25 15:24]: >> On Thu, Aug 25, 2011 at 2:50 AM, Wolfgang Schnerring wrote: >>> So I'd like to propose to do the split the other way around: Not >>> extract the core into something else and leave only a hollowed-out >>> shell of integration and miscellany stuff behind, but rather tighten >>> zope.component to its core and move the optional integration bits out >>> of it, into separate packages. >> >> I would agree if we were starting over. But the damage is done >> and stripping zope.component to its core would be backwards >> incompatible now. > > Why? zope.component already uses extras_require to signify the various > integration parts: [persistentregistry,security,zcml]. But it still contains code to go with those dependencies. To clean this up, you'd have to remove that code, which would cause breakage. > As far as I understand the thrust of the zope.registry effort, it is to > untangle those to make porting easier (which requires those bits not to > be in the same package, I guess, because of import problems or > whatnot?). > > I think the same effect could also be achieved by splitting these > integration bits into separate packages, and leaving the > extras_require's in zope.component to depend on said new packages, > couldn't it? It could if you didn't care about backwards compatibility. > > But that's only technicalities in search of meaningfully preserving the > name zope.component for the core package (because that's the name it > always had), and... It would still have that name. > >> This is, OTOH, an opportunity to maybe come up with a more appealing >> name. While I like the term "component", my sense is that it probably >> feels too heavy to a lot of Python programmers. "Registry" is at least >> as bad and doesn't reflect the real use case. > > ... I agree that an alternative is to give the core a new name. > > However, what's important to me is that we try to make packages > cohesive, and that we try to make integration between packages > understandable. That's everyone's goal. The current contents of zope.component aren't all that cohesive. I haven't looked at the registry branch but I assume and hope that the registry package includes the core functionality. > > The current zope.component, because it came out of the Zope3 monolith, That's not right. When Zope3 was managed as a single whole, zope.component was far more cohesive and less tangled than it is now. It gained a bunch of cruft in the rush to kill zope.app.component when code was moved from zope.app.component was mistakenly moved to zope.component. The reason we created zope.app in the first place was to prevent application-framework-specific policies from polluting the more general packages. > contains integration bits to various other Zope packages: > - zope.event I think treating integration with zope.event as core would be reasonable. > - zope.security > - zope.configuration > - ZODB > > In that light, it makes a lot of sense to me to have two (or more?) > packages, "core" and "integration", but I'd *very* much like them to be > named in a way that one can tell this fact from their names. Me too. I wish the destruction of zope.app.component had happened differently. I'd like to have meaningful names, but I'd rather not incur more backwards incompatibility to get them. It's certainly valid to argue for the backward incompatibility. It's a tradeoff. > What remains is the issue that zope.component *also* contains code for > the thread-local site concept -- which doesn't feel like an integration > with another package, but might not be considered core functionality, > either (I'm not sure yet but I lean towards considering it core). IMO, what's core is a way to plug in component registries, not a particular strategy for component registries. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Thu, Aug 25, 2011 at 2:50 AM, Wolfgang Schnerring wrote: ... > So I'd like to propose to do the split the other way around: Not > extract the core into something else and leave only a hollowed-out > shell of integration and miscellany stuff behind, but rather tighten > zope.component to its core and move the optional integration bits out > of it, into separate packages. > > What do people think? I would agree if we were starting over. But the damage is done and stripping zope.component to its core would be backwards incompatible now. This is, OTOH, an opportunity to maybe come up with a more appealing name. While I like the term "component", my sense is that it probably feels too heavy to a lot of Python programmers. "Registry" is at least as bad and doesn't reflect the real use case. Maybe something like "zope.plugins" would be better. When I try to explain zope.component to people, I often explain it as a good generic plugin mechanism. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Pluggable template engine
What problem does this solve? Jim On Wed, Jul 20, 2011 at 11:24 AM, Malthe Borch wrote: > I've refactored the ``pagetemplate`` module to realistically support > plugging in an alternative implementation of the parser and > interpreter. > > http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/ > > Two new interfaces are added which serve as the plugging point see > ``IPageTemplateEngine`` and ``IPageTemplateProgram`` in this module: > > http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/src/zope/pagetemplate/interfaces.py?rev=122300&view=markup > > I'd like to propose merging this into trunk. > > \malthe > ___ > 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 ) > -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Configurable Blob Permissions ZODB
On Fri, Jun 17, 2011 at 8:45 AM, Robert Niederreiter wrote: > Am Freitag, den 17.06.2011, 08:06 -0400 schrieb Jim Fulton: >> > Any doubts, suggestions, other ideas? >> >> -1 for a new configuration option. >> >> I would rather just have write permission *only* removed >> from committed blob files. Read permissions should be controlled >> by existing mechanisms such as umask. > > So changing the creation mode for folders to 755 and for blobs to 444 > would be the solution then. right? No. Use the default mode for folders and files, but removing write access on committed blob files. > Has this a chance to get into the next ZODB release? Of course, but it's not a priority for me personally. I'd be happy to review a patch with tests. I'd even consider this a bug fix, rather than a feature, so it could get into a 3.10 release. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Configurable Blob Permissions ZODB
On Fri, Jun 17, 2011 at 4:53 AM, Robert Niederreiter wrote: > Hi, > > Refering to this bug report > > https://bugs.launchpad.net/zodb/+bug/683751 > > And this usecases > > http://stackoverflow.com/questions/6168566/collective-xsendfile-zodb-blobs-and-unix-file-permissions > > It would be great if create mode of blobs would be configurable in ZODB > directly. > > For UNIX Systems there could be 2 flags for folder creation mode and > blob file permissions, i.e. > > BLOB_FOLDER_MODE = 750 > BLOB_FILE_PERMISSIONS = stat.S_IRUSR | stat.S_IRGRP > > which are used then at the appropriate places. > See here: http://pastebin.com/wNLYyXvw > > I don't know how this refers to NTFS, though. > > Further this configuration flags should be available in ZOPE and ZEO > Server configuration files. > > Any doubts, suggestions, other ideas? -1 for a new configuration option. I would rather just have write permission *only* removed from committed blob files. Read permissions should be controlled by existing mechanisms such as umask. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] component registry navelgazing
On Mon, Jun 13, 2011 at 12:38 PM, Jim Fulton wrote: > On Sun, Jun 12, 2011 at 4:48 PM, Chris McDonough wrote: >> Currently if you ask a registry to singly-adapt an object to an >> interface, and the object you're trying to adapt implements that >> interface, here's what happens: >> >>>>> from zope.component.registry import Components >>>>> c = Components() >>>>> from zope.interface import Interface, implements >>>>> class IFoo(Interface): pass >> ... >>>>> class Foo(object): >> ... implements(IFoo) >> ... >>>>> foo = Foo() >>>>> c.queryAdapter(IFoo, foo) >> >> >> In order to get the object itself back from such an adaptation, you need >> to use the default= argument. >> >>>>> c.queryAdapter(IFoo, foo, default=foo) >> <__main__.Foo object at 0x24a3910> >> >> This seems slightly inconsistent with the adaptation worldview imposed >> by getAdapter/queryAdapter. I think it would be more consistent if >> "c.queryAdapter(IFoo, foo)" returned foo if foo already implemented IFoo >> and there was no other more specific adapter registered for the IFoo/foo >> pair in the registry, no? > > I don't know what getAdapter/queryAdapter you're referring to in > "This seems slightly inconsistent with the adaptation worldview imposed > by getAdapter/queryAdapter." > > Do you mean " This seems slightly inconsistent with the adaptation > worldview imposed > by interface __call__." ? By the later messages, I can see that that is what you meant to say. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] component registry navelgazing
On Sun, Jun 12, 2011 at 4:48 PM, Chris McDonough wrote: > Currently if you ask a registry to singly-adapt an object to an > interface, and the object you're trying to adapt implements that > interface, here's what happens: > >>>> from zope.component.registry import Components >>>> c = Components() >>>> from zope.interface import Interface, implements >>>> class IFoo(Interface): pass > ... >>>> class Foo(object): > ... implements(IFoo) > ... >>>> foo = Foo() >>>> c.queryAdapter(IFoo, foo) > > > In order to get the object itself back from such an adaptation, you need > to use the default= argument. > >>>> c.queryAdapter(IFoo, foo, default=foo) > <__main__.Foo object at 0x24a3910> > > This seems slightly inconsistent with the adaptation worldview imposed > by getAdapter/queryAdapter. I think it would be more consistent if > "c.queryAdapter(IFoo, foo)" returned foo if foo already implemented IFoo > and there was no other more specific adapter registered for the IFoo/foo > pair in the registry, no? I don't know what getAdapter/queryAdapter you're referring to in "This seems slightly inconsistent with the adaptation worldview imposed by getAdapter/queryAdapter." Do you mean " This seems slightly inconsistent with the adaptation worldview imposed by interface __call__." ? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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 )
