Chris McDonough wrote:
Chris McDonough wrote:
If some set of ZCA APIs made it the responsibility of the *caller* to
invoke
the adapter with arguments would go a long way between normalizing the
difference between utilities and adapters (because they would essentially
then
be the same
Hanno Schlichting wrote:
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote:
Hmm, I may be missing something here, but if Foo implements IFoo, then
the getAdapter lookup for it will short circuit, leading you into
infinite recursion. Except that it doesn't:
[snip
Hey,
Christian Theune wrote:
[snip]
Another option would be to provide a backwards-compatibility mode of our
code which can be switched on and off.
Your notion of bringing the component lookup mechanics closer to being a
language feature is very intriguing and I like it a lot. However, if
Hi there,
Introduction
So now that we've had some discussion and to exit the bikeshed phase,
let's see about getting some volunteers to work on this.
The goal here is to make interfaces disappear into the language as much
as possible. This means that I'll ignore backwards
Thomas Lotze wrote:
Martijn Faassen wrote:
Are people okay with the proposed semantics?
I am.
Would people be okay with such an upgrade path? Any better ideas?
I'm not comfortable with the idea of an automatic fall-back for IFoo(x, y)
but maybe that changes after thinking about
Chris Withers wrote:
[snip]
I'd propose just having:
3.x - old semantics
4.x - new semantics
That's the Python 3 upgrade scenario, without conversion scripts even. :)
I think this would block people from upgrading to use the new semantics
way too long, as they'd need to ensure all their
Marius Gedminas wrote:
[snip]
+0.5 --- I can live with it. Backwards incompatibility with IFoo(one,
default) will be a slight inconvenience. There were proposals I liked
more (IFoo.adapt(), IFoo.utility()) and proposals I liked less
(IFoo((one, two, we_like_parentheses,
Chris Withers wrote:
Martijn Faassen wrote:
Simple adaptation:
IFoo(adapted)
Is there an implied default of None here or would a ComponentLookupError
be raised?
I'd say a ComponentLookupError. Doesn't it do that now? Anyway, I'd say
if you want a default specify it, otherwise it'll
Baiju M wrote:
from zope.__future__ import new_adapter_lookup?
Let's leave how special names are created in Python to Python.
We already have __parent__, __annotation__ etc.
What if Python brings a special name which we are using with
a different semantics.
Python's not going to
Marius Gedminas wrote:
[snip]
The utilities must be singletons logic hardcoded in the ZCA.
provideAdapter(factory, adapts=(one, two, three))
provideAdapter(factory, adapts=(one, two))
provideAdapter(factory, adapts=(one, ))
The natural progression, to me, is
provideAdapter(factory,
Hey,
Jan-Wijbrand Kolman wrote:
I'm about to work a bit on z3c.schema2json [1]. As has been briefly
discussed before (a while ago [2]), z3c. schema2json is so similar to
z3c.schema2xml [3] in what it does and how it does it, that I wonder
about merging the two packages somehow.
One way
Thomas Lotze wrote:
Martijn Faassen wrote:
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility
* it must be ruled out. (...or does it, really?)
I'm thinking that this...
* Martijn Faassen faas...@startifact.com [2009-11-25 22:21]:
The last one won't work if we want to maintain backwards compatibility.
The second argument is the default.
is a valid argument, while this...
* Tres
Shane Hathaway wrote:
[I talk about backwards compatibility issues with some proposed API changes,
but this modification doesn't have this issue]
Here is an interface decorator I intend to try out soon. It adds
convenient component lookup methods to a particular interface without
requiring
Thomas Lotze wrote:
[snip]
Then let me suggest not changing the call signature of an interface at all
but only add one or a few new methods. Firstly, this will keep backwards
compatibility even with code that adapts a tuple, and secondly, it allows
us to implement a simple and consistent API
Hi there,
Reading the thread Chris McDonough started (and ended) about modifying
the way utility registration works reminded me of the following
thinking. It's quite independent and probably even antithetical to
Chris's approach as it uses interfaces, but that's fine.
The goal is to make it
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility.
The second argument is the default.
Regards,
Martijn
Hey,
Fabio Tranchitella wrote:
Anyone willing to make a new release of zope.component and zope.sendmmail,
or give me the pypi access to do it?
What's your pypi username?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Fabio Tranchitella wrote:
Hello,
* 2009-11-16 10:25, Martijn Faassen wrote:
Anyone willing to make a new release of zope.component and zope.sendmmail,
or give me the pypi access to do it?
What's your pypi username?
kobold
I've added you for zope.component. You already had release access
exar...@twistedmatrix.com wrote:
Hi,
I've just contributed a patch to CPython adding os.initgroups based on
this extension module:
http://svn.zope.org/Zope/trunk/src/initgroups/
The CPython ticket is here:
http://bugs.python.org/issue7333
I don't think there should be any
exar...@twistedmatrix.com wrote:
I don't think there should be any licensing issues, as the ZPL is pretty
permissive and the code is very short. However, if there are, could the
code in question be relicensed for CPython under the Python license?
That was 4 out of 7 board members replying,
Thomas Lotze wrote:
Thomas Lotze wrote:
While writing tests for the zope.site.hooks module I'm moving to
zope.component, I notice that the module calls getSiteManager() on an site
object. Such an object isn't technically required to implement an
interface that declares that method, but
Chris McDonough wrote:
So were any Zope talks/tutorials accepted?
I have no idea, besides BFG, which is at the very least Zope related. :)
Lennart?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Fabio Tranchitella wrote:
[snip]
I tried to implement my idea here:
svn://svn.zope.org/repos/main/zope.component/branches/conditional-zope.security
This is a quite intrusive change, so please take it as a suggestion and
not as a real proposal: is this the right approach?
That's
Fabio Tranchitella wrote:
[snip]
All the proxying stuff can be made optional with conditional imports.
I think the only solution to make zope.security optional without
removing the permission attribute is to do something like:
try:
from zope.security.zcml import Permission
except
Fabio Tranchitella wrote:
[snip]
Anyway, I'm fine with what Martijn proposed if nobody else supports my
idea.
I'm okay with *not* doing the split up and going with your idea, but I
think eventually such a split up would simplify things. One advantage
would be that someone could examine
Martin Aspeli wrote:
Hanno Schlichting wrote:
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen faas...@startifact.com
wrote:
[ztk.cfg] contains a line
allow-picked-versions = false
I agree with Thomas that we should remove this from ztk.cfg, as if we
publish this for reuse we don't
Martin Aspeli wrote:
Martin Aspeli wrote:
Right, sorry, I must've been tired when I read this. In my mind, I read
it as disallow-picked-versions = false. :)
No, I'm not crazy after all. The thread is about *removing*
allow-picked-versions=false i.e. allowing versions to be picked. I
Tarek Ziade wrote:
Log message for revision 104933:
comparing requirement locations instead of requirement objects
Did I miss the CHANGES.txt update?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Yay! Zope's caveman spin-off, Grok, finally got its 1.0 release today!
http://grok.zope.org
Thanks should also go to all Zope hackers for helping to provide the
foundation for Grok!
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Jim Fulton wrote:
[snip]
In any case, I agree it should be dropped from the ZTK.
+1 on dropping it too.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
Tim Hoffman wrote:
On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli optilude+li...@gmail.com
wrote:
Martijn Faassen wrote:
Please don't add new dependencies to zope.component. Even optional ones,
IMHO. It makes it harder to re-use for others and more complex to
understand. Many people (e.g
Hanno Schlichting wrote:
On Mon, Oct 5, 2009 at 1:18 PM, Martin Aspeli optilude+li...@gmail.com
wrote:
Fabio Tranchitella wrote:
* 2009-10-05 12:15, Martin Aspeli wrote:
Would anyone mind making a 3.5.1 release, or else give me PyPI rights so
that I can do it myself.
Shouldn't this be
Hi there,
To quote Thomas Lotze in another discussion:
[ztk.cfg] contains a line
allow-picked-versions = false
which makes buildout complain if it ends up using a package whose
version it had to pick from the index, so you're required to specify a
version for every package used by
Hey,
Thomas Lotze wrote:
[snip]
I mentioned the zcml extra only because that's how zope.component has to
do with the security concept already, as a motivation of why I'm letting
go of my opposition to introducing more of that concept into
zope.component.
I think it would be interesting to
Thomas Lotze wrote:
Martijn Faassen wrote:
Whether ztk.cfg can be reused directly or whether we should extract
something in it with just the version indicators I'm not sure about. I've
noticed when modifying the buildout.cfg of the ZTK to add
z3c.recipe.depgraph support that I had to pin
Hey,
Hanno Schlichting wrote:
[snip]
I don't see how a ZTK meta-egg would be of any value. Given that the
number of packages included in the ZTK will change quite a bit over
time, it doesn't make sense to depend on a ZTK egg for a package, as
it doesn't provide any real stable contract. An
Thomas Lotze wrote:
[snip]
- make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a
versioned URL
I agree we should make it available under a versioned URL somehow.
Whether ztk.cfg can be reused directly or whether we should extract
something in it with just the version
Hey,
Thomas Lotze wrote:
zope.site.hooks is a rather light-weight module that is concerned with
the concept of a current site, where the notion of a site is used in the
same sense as in zope.component, which actually prefers to only talk
about a component registry. In contrast, the rest of
Thomas Lotze wrote:
Having worked on and released new versions of a few ZTK packages recently,
I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as
there doesn't seem to be an agreed process about this and in an attempt
not to step on anyone's toes, I'd like to ask first
Hi there,
Albertas Agejevas wrote:
[snip]
About a year ago zope.app.catalog as been moved to zope.catalog. I
think during this move there was a unique opportunity to leave these
event handlers behind in zope.app.catalog, so that the no .app
version is free of these forced choices.
Doing
Hey,
Thomas Lotze wrote:
[snip]
I think I'll release the current zope.error later today so people get the
benefit of the lighter dependencies.
Given you access to this too. :)
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Thomas Lotze wrote:
[snip]
Could someone with the appropriate privileges please grant me PyPI access
to the two packages so I can make releases? (Though releasing zope.site
might wait until another issue involving it has been resolved.)
I've given you access to both.
Regards,
Martijn
Thomas Lotze wrote:
Martijn Faassen wrote:
Thanks for doing this analysis! It'd be great if you could turn this into
a proposal for future actions...
Do you mean a proposal that would go in the Proposals section of the ztk
docs?
A proposal on the mailing list to start with, but of course
Albertas Agejevas wrote:
On Tue, Sep 29, 2009 at 01:09:08PM +0200, Martijn Faassen wrote:
About a year ago zope.app.catalog as been moved to zope.catalog. I
think during this move there was a unique opportunity to leave these
event handlers behind in zope.app.catalog, so that the no .app
Thomas Lotze wrote:
Martijn Faassen wrote:
* zope.contenttype: we should analyze what is using zope.contenttype.
Of the packages mentioned in ztk.cfg, zope.browserresource, zope.app.file
and zope.app.onlinehelp are. There's also zope.mimetype which seems to be
concerned with the same
Thomas Lotze wrote:
I just noticed that zope.site depends on zope.app.publication, both via
configure.zcml and the tests. The dependency isn't currently declared.
On the other hand, zope.app.publication doesn't yet depend on zope.site.
I'd like to get rid of the dependency of zope.site on
Hey,
Generally I believe that these rules if strictly applied wouldn't result
in a usable ZTK. Hanno already mentions the testing dependencies, which
we've barely started analyzing. Documentation in 'docs' would disqualify
just about any package (and Reinout brings up a few objections).
A
Hi there,
We now have in the ZTK repository also a facility to create dependency
graphs for the packages in the ZTK (thanks to Hanno's z3c.recipe.depgraph).
http://svn.zope.org/zopetoolkit/trunk/
See the README.txt for more information.
I reviewed some dependency graph for the ZTK the other
Jim Fulton wrote:
On Mon, Sep 21, 2009 at 11:19 AM, Martijn Faassen
faas...@startifact.com wrote:
Documentation in 'docs' would disqualify
just about any package (and Reinout brings up a few objections).
I definitively want the option of making documentation executable.
Manuel makes
Zvezdan Petkovic wrote:
On Sep 21, 2009, at 11:42 AM, Martijn Faassen wrote:
* zope.minmax: is this package being used? If not, we could consider
removing it from the ZTK.
It's easy to find that it's used by zope.session.
It is used for conflict resolution.
Thanks for that bit
Jim Fulton wrote:
On Mon, Sep 21, 2009 at 12:47 PM, Martijn Faassen
faas...@startifact.com wrote:
Jim Fulton wrote:
On Mon, Sep 21, 2009 at 11:19 AM, Martijn Faassen
faas...@startifact.com wrote:
Documentation in 'docs' would disqualify
just about any package (and Reinout brings up a few
Hi there,
Christian Theune wrote:
I'm happy with that change, except that it might be worthwhile to
announce policy changes in a separate thread.
Good point. I'll do that in the future; please remind again if it
doesn't happen.
Regards,
Martijn
Christian Theune wrote:
On 09/18/2009 02:04 PM, Stephan Richter wrote:
On Friday 18 September 2009, Christian Theune wrote:
I've also taken the liberty to update the ZTK policy to say that this
should be done. (other steering group members can call me back if they
don't like this policy
Hey,
Christian Theune wrote:
I'd like to suggest a redesign of the IReRaiseException.
I found this when reviewing revision 103682 and stumbled over the naming
of the interfaces and that the interface only mentions a __call__ to
retrieve a fact.
IMHO this pattern smells like we should
Hey,
Christian Theune wrote:
This would be an interface on exceptions, right? Would it try to adapt
exceptions raised to IPublisherExceptionInfo and if successful look at
this attribute? So an exception can either implement this interface
directly, or you could register an adapter for
Hey,
Stephan Richter wrote:
[snip]
-1 from me too. Having the previous version avoids having to look it up in
CHANGES.txt or the tags, which is really lame if you do lots of releasing.
From private conversations here at the Grok sprint with Christian I
think that means that the steering
Hi there,
Unless you think you have a great argument that you think will make
significant portions of the ZTK steering group change their mind on
this, this discussion should now be closed.
We're sticking with our current release policy for the ZTK packages.
This doesn't affect non-ZTK
Thomas Lotze wrote:
I asked about this before; let me do so again before assuming silence to
mean consent:
There's a PathPersistent class in zope.location.pickling which is
decorated with a recent BBB comment, and had been questioned by a XXX
comment for some time before that.
The class
Hey,
I think it would be good if we could (eventually) separate the Zope
Toolkit development documentation (what's published by
docs.zope.org/zopetoolkit now) from the Zope Toolkit release documentation.
Zope Toolkit dev documentation:
* aimed at people who need to *manage* the development of
Thomas Lotze wrote:
What's the oldest Python version the ZTK is supposed to support? 2.4?
The ZTK docs don't seem to say anything about this.
Good point. I think right now the ZTK is supposed to support 2.4 to 2.6
(thanks to Jim's work in particular to fix it). I've added this to the
Zope
Benji York wrote:
On Fri, Sep 11, 2009 at 2:20 AM, Wichert Akkerman wich...@wiggy.net wrote:
Suppose you are working on an app which includes a package that depends on A
= 2.1 to make sure it can use a new API introduced in A 2.1. If you then
add a develop egg for A to do some work on it
Hi there,
Apparently some people are using '0' instead of the next version for
packages in the ZTK.
Please do not do this for ZTK packages. The official policy for
releasing is here.
http://docs.zope.org/zopetoolkit/process/releasing-software.html
It is also all right to use a tool like
Hey,
Jim Fulton wrote:
On Fri, Sep 11, 2009 at 8:55 AM, Martijn Faassen faas...@startifact.com
wrote:
Hi there,
Apparently some people are using '0' instead of the next version for
packages in the ZTK.
Please do not do this for ZTK packages. The official policy for
releasing is here
Gary Poster wrote:
[snip]
...Mmm, what Marius describes works for me, I believe. I've
definitely used that trick and showed it to others, at least. Maybe
it worked by mistake? /me wonders if he was doing something wrong, or
if he remembersbut doesn't take the time to try it again
Jim Fulton wrote:
* it breaks dependencies on development versions which have version
requirements in it (see Wichert's comments on the original thread).
I'm not sure I understand this.
I think your answer is below, and your solution would be to add a == 0
to the dependencies.
We're
Fred Drake wrote:
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen faas...@startifact.com
wrote:
So, could you please follow this policy for ZTK packages in SVN?
I suspect it would help if packages that are part of the ZTK have that
indicated somewhere convenient, like near where
Jim Fulton wrote:
I'm guilty of causing most these packages to violate the standards,
while making their tests pass.
Wasn't my intent to track down the guilty, just ran into this
information and wanted to record it for posterity.
Making their tests pass is of course way more important than
Hey,
Marius Gedminas wrote:
On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote:
On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote:
On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote:
3) [no] superfluous version bumps on the trunk
I don't understand this
Hey,
Christian Theune wrote:
[snip]
Same here. We also ended up in many deadlock situations having to
sacrifice chickens for SVN to resume operations. That's why we started
investigating alternatives which are better at branching and merging.
Please keep up posted. We have a standing offer
Hi there,
What's the status of the ZTK KGS?
Is the stuff still on Jim's branch?
svn+ssh://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs
What's the plan for merging this branch?
Is documentation about it all being written to add to the Zope Toolkit
documentation?
Hi there,
Christian Theune wrote:
a long-standing issue with our mirror of svn.zope.org are the absolute
URLs of externals: they require the repository to be available on a
given URL.
I propose to use relative URLs for externals. I guess a complete update
isn't necessary, but I'd like to
Hanno Schlichting wrote:
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassenfaas...@startifact.com wrote:
Christian Theune wrote:
However, this requires Subversion 1.5 which we are using on the server
already, but I don't know whether we assume clients are 1.5 or higher.
I certainly still use a
Jens Vagelpohl wrote:
On Sep 9, 2009, at 15:30 , Martijn Faassen wrote:
Ah, I perhaps misunderstood. I figured the resolving of relative
externals would be a problem with a Subversion 1.4.x client.
There's two different issues being confused here.
SVN 1.4 clients will work with SVN
Hanno Schlichting wrote:
On Thu, Aug 27, 2009 at 8:10 PM, Tres Seavertsea...@palladion.com wrote:
Stephan Richter wrote:
You can not require a minor version in setup.py.
Huh? setuptools doesn't care about how many dots are in the dependency.
What Stefan probably meant here was: You
Hey,
Martin Aspeli wrote:
- What is the current version of ZTK? 1.0? 1.0-something? 3.5? Note
that docs.zope.org/zopetoolkit talks about 3.5.
1.0. It's not released yet though. I've corrected some of that
documentation.
- What is the canonical location of a ZTK KGS? I'm locking for a
Dan Korostelev wrote:
2009/8/25 Martijn Faassen faas...@startifact.com:
You have zope.browsermenu, zope.browserpage, zope.browserresource. I
propose instead we name them zope.menu, zope.page and zope.resource.
-1 These things are really only for browser, and ZCML directives are
in browser
Jim Fulton wrote:
Cool. I just updated the .rst file. Someone else has to update the web site.
:)
It's automatically updated every day (or faster?) by a cron-job. This
makes life really easy for us developers to publish information online. :)
Regards,
Martijn
Jim Fulton wrote:
On Tue, Aug 25, 2009 at 12:21 PM, Martijn Faassenfaas...@startifact.com
wrote:
...
That sounds reasonable, as long as it is documented. I got confused at
first about the term 'test branch', but you just mean a non-maintenance
branch of a package to do some development on.
Jim Fulton wrote:
On Tue, Aug 11, 2009 at 8:02 AM, Martijn Faassenfaas...@startifact.com
wrote:
[snip]
Ah, that's cool. I take it it's not yet possible to do without the test
extra entirely and let buildout rely on the test_require section? That
way we could do without duplication.
That's
Thomas Lotze wrote:
Martijn Faassen wrote:
One question to ask is whether getParent and getParents are used all over
the place or just by zope.traversing. If they're only used by
zope.traversing we might not want to move them to a more general place,
but perhaps we can even see about
Jim Fulton wrote:
On Tue, Aug 11, 2009 at 5:39 PM, Jim Fultonj...@zope.com wrote:
...
Why is zope.ucol in the list? It's a pain to install (and thus test)
because it needs ICU.
BTW, I hope that zope.ucol isn't needed (when you need unicode
collation badly enough that you're willing to
Jim Fulton wrote:
I do think we need a computer readable system that includes information
like this:
* whether a project is in a KGS (such as for the ZTK)
* whether a project is used to test a KGS (a package not in the ZTK but
used to test whether changes don't induce breakage, let's say,
Benji York wrote:
On Fri, Aug 14, 2009 at 2:51 PM, Jim Fultonj...@zope.com wrote:
Keep in mind that the thing we're talking about is pretty simple,
basically a single file. Branches beyond a test branch seem like
overkill. Maybe I missunderstand you. What sorts of branches did you
have in
Jim Fulton wrote:
On Fri, Aug 14, 2009 at 1:03 PM, Chris Withersch...@simplistix.co.uk wrote:
...
One question, and I know I'm late in on this so feel free to point me at
previous discussions, but say the KGS uses some.egg 1.0.0, a bug gets fixed
in some.egg and 1.0.1 is released. Does a
Jim Fulton wrote:
On Sat, Jul 4, 2009 at 7:33 AM, Christian Theunec...@gocept.com wrote:
So, if you see that a package is missing or is classified in the wrong
way, then please speak up.
I think zope.wfmc and zope.app.wfmc should be removed. I don't think
they're widely used. I don't use
Hey,
Shane Hathaway wrote:
[snip]
Few developers care about XML-RPC these days. Most web developers are
now working with REST, JSON, and other similar stuff. It's probably
best to move all XML-RPC artifacts, including those in zope.publisher,
to a single package, so that most developers
Dan Korostelev wrote:
2009/8/21 Dan Korostelev nad...@gmail.com:
Browser view directives (browser:page and friends) - move this to some
zope.browserpage package and make its structure more clean, so
people could understand the magic of browser page class generation.
:-)
Silly me, I
Dan Korostelev wrote:
2009/8/24 Stephan Richter srich...@cosmos.phy.tufts.edu:
On Friday 21 August 2009, Dan Korostelev wrote:
BrowserSkinsVocabulary - this can be moved to zope.publisher.browser
and rewritten with zope.schema's SimpleVocabulary not to introduce
dependency on
Hey,
Jim Fulton wrote:
[snip]
A. Suck it up and live with the deprecation warnings until we get rid
of zope.app.zcmlfiles
B. Remove the security declaration for mhlib from globalmodules.zcml.
Is anyone actually building web applications that publish MH mail
folders?
C. Stop including
Hi there,
Here are some steering-groupish responses.
General note: I'm quite enthusiastic about the general plan to clean up
zope.app.publisher! Thanks for bringing this up!
Dan Korostelev wrote:
Menu mechanism (the browser:menuItem directive and friends) - move
this to the new
Hi there,
Fabio Tranchitella wrote:
[snip]
Will we have an official buildbot instance somewhere under the zope.org
domain? In this case, I'm willing to administer and maintain it, if nobody
else steps in.
I'd be happy to see this. We can do this with a DNS thing
(buildout.zope.org) or we can
Stephan Richter wrote:
On Wednesday 12 August 2009, Jim Fulton wrote:
I'm not sure why this all has to be computer readable. What is the
use case for computer readable knowledge of whether a package is in
the kgs or just used to test it? What is the need for computer
readable information
Hey Dan,
See also my feedback in the original thread.
Dan Korostelev wrote:
Four new packages have been introduced:
See my comment on naming. I think we should call 'zope.menu',
'zope.page', 'zope.resource'.
* zope.browsermenu - browser menu system, without any changes. :-)
*
Hey,
On Tue, Aug 11, 2009 at 10:31 AM, Jim Fultonj...@zope.com wrote:
On Thu, Aug 6, 2009 at 1:05 PM, Martijn Faassenfaas...@startifact.com wrote:
[snip]
In a way the consensus should be reflected by the list you mention:
http://docs.zope.org/zopetoolkit/about/packages.html
Do you mean the
Hey,
Jim Fulton wrote:
[snip]
Id like us to say something along the lines of:
If your tests have additional dependencies, define test extra with
these dependencies. Also define tests_require and test_suite so that
your package supports the test command.
(Not verbatim and we should give
Jim Fulton wrote:
On Thu, Aug 6, 2009 at 12:16 PM, Martijn Faassenfaas...@startifact.com
wrote:
[snip]
Could you give an example ofa 'test package'? I'm having trouble
thinking of what these might be.
Perhaps Grok (or keas ), or some higher-level framework or application
built with the
Hey,
Jim Fulton wrote:
On Thu, Aug 6, 2009 at 12:31 PM, Martijn Faassenfaas...@startifact.com
wrote:
[snip]
I certainly appreciate the participation. I'm sure you appreciate the
problem with breakage, although I'm not sure you appreciate it as much
as I do. :) I think we've had too much
Jim Fulton wrote:
[snip]
Except that the under review list is pretty long. Shall we include
everything that's under review as a starting point? We can always
lobby to remove some later.
Yes, I'm +1 on being inclusive. I want to be pretty aggressive about
removal, but we need to get from here
Hey,
Fabio Tranchitella wrote:
[snip]
Jim suggested that zope.container shouldn't assume that I want to use
zope.publisher, and thus it is not a good idea to move the configuration of
the XMLRPC traversers to zope.container.
I agree with that; I'd prefer zope.container to be publisher
201 - 300 of 1200 matches
Mail list logo
