Re: [Zope-dev] Security fixes from Plone hotfix ported to Zope ?
Is there any plan to make new releases of Zope 2.12 and Zope 2.13 integrating the patches that are meaningful for pure-Zope (non-Plone) applications ? Plone doesn't always use the latest version of Zope. These are backports. Matt smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Status of github migration
Tres Seaver wrote: Because it is a helluva lot of work, which can't be trivially scripted (things can go wrong: each project needs a person who knows it well to review the migrated repo). When Plone did this the people involved wrote some scripts https://github.com/plone/svn-migrate I'm sure they'd be willing to help move all of Zope across, too. Should I have a word? Matt ___ 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
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. 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. Matthew ___ 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.
Jens Vagelpohl wrote: Maintaining the chain of custody doesn't just consist of selecting pull requests or patches coming from somewhere. It also means verifying the contributor - be it the one who is creating the patch or pull request or the one who is merging new code into the repository - is who he claims to be. In the current setup the verification of the merging contributor is done using unique SSH logins with keys for every contributor, which works very well. This is how github works, too. The only difference is that the admin UI for changing your SSH key is on the github site, not the ZF site. By the way, there's no problem converting project repositories on an as-needed basis to Git repositories in the current infrastructure. But I feel the discussion is more about GitHub or nothing. Apologies to anyone who feels offended, I'm just speaking privately here under the impression that no one has mentioned any alternative solution. There are alternative git solutions, all of which would be preferable to the current SVN setup. GitHub is just a hosted service that many of us are already using and have admin helper tools for. By the same token, the let's not use github side of this discussion feels to me like self-hosted or nothing. We absolutely should have backups/mirrors of what's on github, but we shouldn't abandon the idea of using github because we're only going to be using 40% of the great things it adds on top of git, rather than 100%. Matt ___ 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 2011-11-03, at 0025, Chris Withers wrote: I'm experimenting with using nose as an alternative to zope.testrunner so I can take advantage of the junit and cobertura compatible xml output offered. Using http://pypi.python.org/pypi/collective.xmltestreport might be easier? Not sure if it gives you everything you need, but works well for us Plonies. Matt ___ 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.sendmail and critical transaction errors.
On 2010-06-23, at 1359, Laurence Rowe wrote: I think the Before Commit Hook option is probably best here. DirectMailDelivery should only be used for testing anyway, or at least only on very small sites in production - QueuedMailDelivery will scale better. Sorry, I'm somewhat late to this thread, in the process of moving to Germany and missed it. I've committed some partial fixes that don't rely on using transaction hooks: - Products.MailHost now no longer duplicates code in zope.sendmail - zope.sendmail mailers grow a vote() method to allow them to veto transactions if they know they'll fail. Currently SMTPMailer will go as far as HELO before accepting the vote. - All exceptions in tpc_finish are redirected to the log instead of being raised This is similar to what Wichert described, the upshot is that missing and non-connectable servers cause a transaction abort but deeper problems can fail part-way through sending the emails (as currently happens) but without breaking the ZODB contracts. It has been suggested on IRC that we should also have an event fire on failed mail sending so applications can display a message in the UI, which seems like a good idea. This obviously isn't perfect but it retains the basic functionality of sendmail as it is currently. Matt ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.13 - next steps
On 2010-06-13, at 1348, Hanno Schlichting wrote: On Sat, Jun 12, 2010 at 9:29 PM, David Glick davidgl...@groundwire.org wrote: Has the process of reviewing RestrictedPython against a new Python release been documented anywhere? Not that I know of. Stephan Richter and Sidnei da Silva were the last to do these reviews, maybe they know. There was talk of having a BoF at a conference or similar about the process of doing the RestrictedPython security audits, to make sure it doesn't become an arcane lost skill, any chance this could happen at PloneConf2010? Matt ___ 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] Zope2 ZMI and HTML5
On 2010-02-06, at 1257, Charlie Clark wrote: Migrating from DTML to ZPT would add weight to the dog food argument and should be fairly straightforward. ZPT came on the scene shortly after I started playing with Zope and is one of the biggest reasons for me sticking with it. The ZMI is probably the last big dependent of DTML in Zope 2 so it would be nice to be able to remove that dependency for Zope 2. It seems like a lot of work for no gain. I can think of a couple of examples where DTML templates are monkey-patched in Plone and none of those are anything particularly vital. DTML works for the ZMI, new pages can be written in ZPT, why bother going back and changing them all? I mean, how often do you really need to do maintenance on the security form, for example? Matt ___ 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] Zope2 ZMI and HTML5
with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI? This is such a minor thing that if we do ever get to a stage where we're having to get rid of the frames it would just be a patch. I never use frames in the ZMI myself, I just hit manage_main Matt ___ 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] Zope2 and WSGI
On 2009-12-22, at 1627, Hanno Schlichting wrote: I'd love to have Zope2 actually support WSGI out-of-the-box. It should probably be based on either a simplified repoze.zope2 codebase or simply something that gets the job done. So what's your goal with this and is there any way I can help? I'm working on a Plone 4 site running as part of a WSGI stack at the moment. It's using repoze and I've already come across some nasty bugs, so I'd be happy to volunteer time for testing and bugfixing. Matt ___ 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] New release of zope.interface
On 2009-12-23, at 0624, Marius Gedminas wrote: Releasing 3.8.5 now. …and it's broken. The testrunner directory isn't included in the tarball so egg_info fails. In addition, the PyPI page has been destroyed because of a ReST syntax error somewhere. Matt ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? Matt ___ 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] make zope.component.registry.Components inherit from dict?
Hi Chris,
On 2009-11-24, at 0324, Chris McDonough wrote:
In repoze.bfg, we've actually decided to use a subclass of the
component
registry which also inherits from dict. This makes it possible to
spell
common unnamed utility registrations and lookups as:
utility = SomeUtilityImplementation()
registry['someutility'] = utility
While I'm all for simplification, this makes very little sense to me.
If this is an unnamed registration why is there a name ('someutility')
involved?
If it was a named registration against Interface, or if the key was an
interface/dotted name that'd make sense.
Could you expand on what the key is supposed to represent?
Matt
___
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] make zope.component.registry.Components inherit from dict?
You may have Zope Component Developer's Eyes, a common disease in these parts. ;-) The goggles, they do nothing. Under the hood, the system does something like this when a root factory needs to be registered: from repoze.bfg.interfaces import IRootFactory from zope.component import getSiteManager reg = getSiteManager() reg.registerUtility(root_factory, IRootFactory) Then when the system needs to look it up again, it needs to do this: root_factory = getUtility(IRootFactory) Looks sensible. If you notice, there is no key for this utility other than the IRootFactory interface (it's unnamed). In this case, also, there will never be a registration made against a subclass of IRootFactory. In this scenario, if we weren't using ZCA at all, we'd probably do something like this: reg = get_some_registry() reg['root_factory'] = root_factory Sure. In a system like this, there are no interfaces; the string 'root_factory' performs the same job as the IRootFactory interface for registration and lookup. I'd like to make the ZCA registry operate like this. There's really no reason for there to be an interface hanging around to represent this thing: we're using the ZCA as a complicated dictionary here. Right, but I think mixing the two is just going to be confusing. Your alternative spelling may well be useful, but only if it works within the confines of the ZCA itself, otherwise you're just hijacking the component root for your own (nefarious) purposes. A lookup keyed entirely on strings and not interfaces is perfectly possible using the ZCA, just register your utility to provide z.i.Interface and name it. Your semantics are the same as the simple dictionary use-case, but it doesn't force people to choose one means of access over another. Creating shim methods for the dict-interface (or a useful subset) could hook in registration, querying and unregistration of utilities in a vaguely sensible way. But, here is where the ZCA eyes come back into play, I wouldn't add this to the ZCA itself. One reason being that Hanno's been working on a more useful persistent component root for Zope that brings in bits of OFS, hooking a dict in there would just be confusing. So, if only there was a way of specifying a new set of functions and defining a way of mapping them onto an existing object… I'd say make an adapter that adds the dict interface as a wrapper around named utilities and provide that to BFG users. That way you don't pollute the namespace of the ZCA object, interoperability with other code is maintained and you get your user-friendly interface. Matt ___ 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: Site - Locus
On 28 May 2009, at 12:39, Martijn Faassen wrote: * Hm, I wonder whether it has something to do with local utilities. I don't think I'd make this jump. I'd not be averse to a longer package name if it made it more explicit. Matt ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On 26 Apr 2009, at 16:53, Martin Aspeli wrote: We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does. Is there any risk involved in this? It looks ok in theory, just that we're at a4 of Zope 2.12, we should be getting wary of features. We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily. plone.folder is GPL and owned by the Plone Foundation, BTreeFolder2 is ZPL and owned by the Zope Foundation and contributors. This sounds like quite easily from a copy-the-code point of view, but doesn't take account of legal issues. You'd need at least a PF board vote. I doubt the Plone foundation is a Zope contributor, and I'm not sure if their agreements would even be compatible, it may grant Zope Corp some rights that weren't granted to the PF. Matt ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
On 8 Apr 2009, at 16:40, Martijn Faassen wrote: How to get out of that bind? We could consider renaming Zope 3. Is there any potential for this? A thought that occurs to me is we could not rename Zope 2 or Zope 3 but abbreviate Zope 3 to z3 as much as possible. I'm not sure if that's even a good idea, but I think it's a fairly universally understood term for Zope users, and new people wouldn't realise until they asked, at which point they get the explanantion. Matt ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component
On 1 Apr 2009, at 18:25, Chris Rossi wrote: Additionally, if I was grokking Lennart correctly yesterday, __metaclass__ is going away, so the current metaclass implementation is going to need some rejiggering. What was unclear was whether a single implementation could support both =2.5 and =2.6. __metaclass__ is being replaced by a metaclass kwarg to class definition in 3.0, I believe. Matt ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On 3 Mar 2009, at 18:25, Martijn Faassen wrote: Ah, so Plone currently has long term direction as they think 2 releases ahead of just one? Plone 4 discussions are happening around now, there are demos of suggested concepts and people generally working on the codebase. Plone 5 is a long way off, but we have some ideas, for example Hanno has already suggested it should target Python 3.x. 2 major releases in the Plone world is about 3/4 years. Matt (Proud Plone 4 Framework team member, ftr) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On 2 Mar 2009, at 16:33, Martijn Faassen wrote: What is the Zope project? The Zope project is an umbrella project for a number of sub-projects. Its source code is in a repository managed by the Zope Foundation. Within the Zope project, there are a number of projects that ship full-stack web frameworks (or application servers): One of the most striking things about the Zope community (imho) is that we don't have a single central presence. There's no Zope conference, people go to PyCon, EuroPython, PloneConf, etc, they hang out in different irc channels (personally I discuss Zope in #plone, #zope, #zope.de, #plone-framework and #repoze), and this mailing list isn't widely read. Yeah, the people are mostly the same, and you know a Zopista from people outside the community, but there doesn't feel like there's a central community. I couldn't tell you what the Zope Foundation does, for example. To distinguish between these two perspectives on Zope 3, we will introduce a new term: the Zope Framework. Zope 3 should be used to indicate the Zope 3 application server that is one consumer of these libraries. To be explicit we encourage the use of Zope 3 application server to indicate Zope 3 and discourage the use of Zope 3 to indicate the Zope Framework itself. +1 The Zope Framework has a central status within the wider Zope project. It is the core Zope technology ingredient to Zope projects such as Zope 2, Zope 3 and Grok. With it's own IRC channel and mailing lists, that become the canonical place for questions about the ZCA, etc? Either way, +1 A library that at some point in time is considered to be part of the Zope Framework is called a core library. The Zope Framework contains those libraries that are reused by a large number of projects, or that the Zope Framework developers want to promote to be being more widely adopted. The Zope Framework developers especially favor inclusions of libraries that are used by other Zope projects. +1 on everything but the want to promote bit - the libraries will be decided by the same developers they'd be promoted to. I'm -1 on framework bloat to help spread libraries. If a package is truly useful as part of the framework it goes in, if it's just cool I don't think it should. The set of libraries that is core can change over time depending on how these libraries evolve and are used. New libraries considered to be core can be added to the set, and existing libraries once considered core can be removed from the set. We should be careful though, as we cannot just drop libraries from the core without considerable thought. A library being in the core signals a level of commitment to this library. Meh, ish. I think if we make it clear enough in advance we should be fine. If a non-core library is widely used compatibility will have to be maintained, but it doesn't mean we should keep it in core if it doesn't deserve it. * if it has a lot of people who contribute to it from our community, it's likely core. -1, it's a zope community package, but not necessarily part of our framework. * if it's something we want to encourage more consumer platforms use, it's likely core. -1, as stated above. Which libraries should be core to start with? Proposed is to take the ``zope.*`` libraries. We can immediately weed out a lot of libraries that aren't considered core, and we can then start the slower processes of adding and removing from that set over time. zope.* is a good start, but I think it'd be more useful to look at what packages are actually used by everyone that's considered to be a framework user. Libraries may have a different status in the core to convey extra information about them, such as deprecation status. How will this be signalled? As a service to the users of the Zope Framework, the Zope developers also make available lists of version numbers of core libraries that have been tested to work together as a Known Good Set. This receives a version number and is the Zope Framework release. +1 How will the numbering convention work, currently it is in step with Zope3-the-application-server. Currently intermixed with the Zope Framework core there is code that implements a particular user interface, the Zope 3 ZMI. There is a consensus that these application-like parts should be removed from the core set, as that code typically only sees use by a single consumer (the Zope 3 application server). It is not used by other consumers of the framework. +1 Examples of extra libraries are the hurry.query library for constructing catalog queries, the z3c.form related libraries for form generation, and the grokcore.component library which contains a different way to configure components. Sounds sensible. Any library that is developed for integration with the Zope Framework in the Zope repository can be considered extra; extra is the set of libraries that is not in the
