Andreas Jung wrote:
>> Sure, I don't mind. It sits behind an ADSL line with puny uplink (512
>> Kbit/s), but I don't think that will be a problem.
>
> Nothing against your generous offer but I think that trac belongs as
> a central service on the central repository server.
+1, although if we wer
Marius Gedminas wrote:
> The story may be different for Windows users (as usual).
>
> +0.5 for alternatively accepting authenticated https access (I'm not the
> admin, so it doesn't cost me, but I'm also not going to use it)
>
> BTW I've yet to see a firewall that blocks SSH. Am I lucky?
Yup.
Jens Vagelpohl wrote:
> On Apr 2, 2009, at 22:53 , Tres Seaver wrote:
>
>> +1 to making svn-over-http read-only checkouts work.
>
> This is now working. The repository can be reached under...
>
>http://svn.zope.org/repos/main/
Jens, you're my hero :-)
Remind me that I owe you beer next tim
Tres Seaver wrote:
>> - the web front end is ancient and not as good as other options (Trac,
>> WebSVN)
>
> Fixing the web front-end should be a matter for the zope-web list.
The zope-web list is pretty dead...
>> So I thought I'd ask what the plans are now that the foundation owns all
>> the
Andreas Jung wrote:
>> *This* part needs some fixing, largely because Jim's role their is an
>> artifact of ZC's role, now lapsed, as custodians. At a minimum, there
>> should be a group (I suggest the zope-web regulars) who can take over
>> the maintenance of that application. A *different* gro
Christian Theune wrote:
>> See:
>> http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvements
>
> However, this only *allows* clients to manage their password reasonably,
> it doesn't force them to.
Well, you can't force someone to keep their private key private either...
Andreas Jung wrote:
> We might discuss this unhurriedly. To sleep and being in vacation mood
> in order to discuss this now :-) At least the term 'classic' is a NO-GO
> for me.
Why? Would you prefer 'a' or maybe 'old'? ;-)
>>> microsite or somewhere else. The point is that the release should
>>>
Andreas Jung wrote:
>> I'd imagine the full set of releases would appear on the respective
>> parts of classic.zope.org or advanced.zope.org...
>
> *shrug* I don't care if those releases on the new zope2.zope.org
Please not zope2.zope.org, the insane version naming has *got* to stop...
> microsi
Andreas Jung wrote:
>
> Because we can't break existing download URL - neither to old Zope
> releases
I'd imagine the full set of releases would appear on the respective
parts of classic.zope.org or advanced.zope.org...
> nor to old product releases.
I wonder how many of these are actually s
Andrew Milton wrote:
> | Indeed, but "classic" doesn't have any "bad" connotations as far as I'm
> | concerned, and it'll need to keep living as long as Plone relies on it,
> | which will be forever...
>
> Plenty of people use it without plone. You might want to crawl out of
> the vacuum you liv
Andrew Milton wrote:
> | Why does it need to keep living even at old.zope.org?
>
> Why do you care if it does?
Because someone needs to look after the (rather large, ancient and
crufty) zope instance in which it lives, and it keeps on tripping up
innocent passers-by.
I don't think many of thes
Andrew Milton wrote:
> | - mature
> | - stable
> | - maybe not the best choice for new development.
> ^ for you
Indeed, but "classic" doesn't have any "bad" connotations as far as I'm
concerned, and it'll need to keep living as long as Plone relies on it,
which will
Andreas Jung wrote:
> Andrew & others have been working on this issue at the sprint. There is
> consensus that www.zope.org must be turned into landing page with some
> mission statement and then links to the related subprojects. The current
> zope.org site should be moved to old.zope.org (it must
Jim Fulton wrote:
> We and canonical use the Zope Framework. We don't use an
> application. Zope (aka Zope 2) is an extensible application. We (ZC
> and Canonical and others) assemble components from the Zope Framework
> to build our own applications.
Hmm, maybe I got this wrong, but Gary
Jim Fulton wrote:
>> What Martijn has announced and is already being worked on extensively.
>>
>> - Zope A 4.0
>>
>> What was to be Zope 2.12
>>
>> - Zope B 4.0
>>
>> Whatever the next pending release of the Zope 3 appserver stuff was to
>> be. (Need to keep the Canonical and ZC guys happy afterall
Andrew Milton wrote:
> +---[ Chris Withers ]--
> | Remember this:
>
> | Seriously, how do people feel about this?
>
> You can do anything you want with your time... who are we to judge? d8)
Well, if there were no complaints I might do just that...
Chr
Dieter Maurer wrote:
>
> I have been told that there are mirrors of the Zope SVN repository
> providing read access via "http".
Shame none of them is advertised anywhere...
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
Remember this:
http://www.perl.com/pub/a/2001/04/01/parrot.htm
Well, that lead to this:
http://www.parrot.org/
One of the reasons I got suckered into replying was that I thought this
might be the result of some stuff a few of us had talked about at the
Zope BOF at PyCon.
I actually think hav
Dieter Maurer wrote:
> I would not like to enter my password every time I call "svn".
> If this can be arranged, I am content.
It can, and with svn 1.6 it's even secure :-)
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_
Martijn Faassen wrote:
> KGS is two things:
>
> * KGS the software
>
> * KGS the concept
>
> KGS the concept will have a life outside of the Zope world.
I stand by my predication that even the KGS concept will never make it
beyond Zope...
> KGS the
> concept is very easy to implement; you ju
Roger Ineichen wrote:
> Probably a way to go is to make both concept compatible with
> each other. Which probably means we should be able to ignore
> versions in packages if a KGS concept get used?
> (not sure if this is possible)
NO! This is INSANE!
The version requirements in a package should b
Wichert Akkerman wrote:
>> Are there other Python projects that have to deal with such a huge
>> amount of packages and dependencies? I don't know any similar project.
>> So the solution must come from the Zope world (which does not mean that
>> we participate in the packaging toolchain development
Tres Seaver wrote:
> Chris Withers wrote:
>> Tres Seaver wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> I mean an index which supplies the 'simple' PyPI interface, such that we
>>> could tell people to 'easy_install' from it, e.g.:
>
Tres Seaver wrote:
>> Possibly because I am using SVN 1.6.
>
> Then "never" means since 2009-03-20. Or else you have never done a
> checkout from a password-protected SVN-over-HTTP(S) server.
It's been encrypted on Windows for longer than that...
(svn 1.4...)
Chris
--
Simplistix - Content M
Jim Fulton wrote:
>
> On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
>> For me, the ideal would be simply https for everything and using http
>> basic auth for access with more people having access to update the
>> passwd file and maybe Trac or WebSVN for a nice
Hey All,
I got bitten by the current zope subversion setup at PyCon so thought
I'd mail the appropriate groups about it. If this has been covered
elsewhere and I've missed anything, please just point me in the right
direction...
So, svn.zope.org causes me pain at the moment:
- it uses the biz
*looks at the date*
*sigh*
I'll go back to my cave now...
Chris
Chris Withers wrote:
> Tres Seaver wrote:
>> On behalf of the Zope community, I am pleased to announce the creation
>> of the "Zope 4.0" project. After extensive discussion with the Zope
>> wi
Tres Seaver wrote:
> On behalf of the Zope community, I am pleased to announce the creation
> of the "Zope 4.0" project. After extensive discussion with the Zope
> wizards in conclave at PyCon 2009, the new project's website has been
> launched:
>
> http://zopefour.org/
Er?
Little more contex
Hi,
Well, I made some progress in that ZEO instances are just fine to get going.
Here's the buildout.cfg:
[buildout]
parts = zeoinstance
extends = versions2.cfg
[zeoinstance]
recipe = zc.recipe.egg
eggs =
ZODB3
entry-points=
runzeo=ZEO.runzeo:main
zeoctl=ZEO.zeoctl:main
zdrun=zdaemo
Hey All,
I've made some progress on this, here's the buildout:
[buildout]
parts = zopeinstance
extends = versions2.cfg
[zopeinstance]
recipe = zc.recipe.egg
eggs =
zope2
entry-points=
runzope=Zope2.Startup.run:run
zopectl=Zope2.Startup.zopectl:main
scripts = runzope zopectl
initializati
Tobias Rodäbel wrote:
> [zope]
> recipe = zc.recipe.egg:scripts
> eggs = Zope2
So, this gives you mkzopeinstance, right?
(I don't think you need the :scripts
It "worked", as in no errors, but when I tried mkzopeinstance, it
generated an instance, but that instance didn't work:
$ bin/runzope
Trac
Andreas Jung wrote:
>> I think an implementation of a better dependency resolution strategy in
>> buildout would be a good place to start. I think some limited
>> backtracking could go a long way. Anyone interested in working on this?
>
> Why would that be a functionality of zc.buildout? I thin
Tobias Rodäbel wrote:
> My versions.cfg resolved all version conflicts mentioned within this
> thread.
Cool, I'll bear it in mind, but right now I want to try and actually fix
things so they work like they should :-)
cheers,
Chris
___
Zope-Dev mail
Tobias Rodäbel wrote:
> On 28.03.2009, at 00:30, Chris Withers wrote:
>
>> Tobias Rodäbel wrote:
>>> Hi,
>>>
>>> had the same issue tonight. I'm using attached versions.cfg for now.
>>> That works quite well for me.
>> Which issue is this
Tobias Rodäbel wrote:
> Hi,
>
> had the same issue tonight. I'm using attached versions.cfg for now.
> That works quite well for me.
Which issue is this supposed to help with?
Chris
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/ma
Chris Withers wrote:
> Paul Winkler wrote:
>> Well, yeah. The point of the suggestion was specifically to help you
>> get more info about the dependency chain, since pip is more verbose
>> about that than easy_install is.
>
> Well, running buildout -v gives some g
Paul Winkler wrote:
> Well, yeah. The point of the suggestion was specifically to help you
> get more info about the dependency chain, since pip is more verbose
> about that than easy_install is.
Well, running buildout -v gives some good clues, a piece of which is
this:
Getting required 'zop
Paul Winkler wrote:
>> I'm not using easy_install, I'm using buildout...
>>
>> (yeah, I know buildout uses easy_install, but...)
>
> One possibility: try using http://pypi.python.org/pypi/gp.recipe.pip ?
I need to be totally upfront about this:
I'm interested in finding out why something that *s
Andreas Jung wrote:
> One last hint: you might try using 'pip' (instead of 'easy_install').
> 'pip -v' gives you better information about the dependencies pulled in
> and where (but it does not tell you why - at least not obviously).
Engage brain ;-)
I'm not using easy_install, I'm using buildout
Andreas Jung wrote:
> Stop with your approach right now until we have understood what's going
> wrong. Working with a SVN checkout from the trunk works (as said).
I'm interested in actually solving what's wrong ;-)
This feels like buildout doing something wrong, at the very least. It
has a hard-
Chris Withers wrote:
> Got zope.principalregistry 3.7.0.
> While:
>Installing zopetest.
> Error: There is a version conflict.
> We already have: zope.component 3.5.1
> but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
Okay, so I thought I&#
Hey All,
I'm trying to get Zope 2.12 working with buildout, in the absence of
docs, I thought I'd try:
[buildout]
parts = zopetest
[zopetest]
recipe = zc.recipe.egg
interpreter = py
eggs =
zope2
...and was rewarded with:
Got zope.principalregistry 3.7.0.
While:
Installing zopetest.
Erro
Gary Poster wrote:
> Email is maybe the best public way to get in touch with me, though I'm
> happy to share cell phone/skype info privately.
Ditto. I'm here how, anyone fancy food/drink/entertainment this evening?
Chris
___
Zope-Dev maillist - Zop
Hey All,
Who's around at PyCon? If so, when/where are we meeting up?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/
Roger Ineichen wrote:
> What do you do if version x.y works with d.e.d but not with
> d.e.e (because it's borken) and fixed in d.e.f.
You release x.y.1 which has dependencies on d.e.d, >=d.e.f.
> This is a use case where fixing versions in packages doesn't
> work
Sure it does.
> This is the be
Martijn Faassen wrote:
> x.y.z is a bugfix release. If we do it right, there will be no change in
> the API and only small changes in misbehavior. Therefore it seems far
> less likely to me that a package ends *needing* to depend on a minimum
> version.
I don't agree. If your package hsa bugs
Wichert Akkerman wrote:
> I see no useful different between x.y and x.y.z here. All I want is if
> someone installs one of our packages that package will work as expected.
> If a package will only work with a certain revisions of a dependent
> package it has to state say.
Yes.
> If we do not do t
Hanno Schlichting wrote:
> Hi.
>
> Chris Withers wrote:
>> Got zope.interface 3.5.1.
>>
>> Any chance someone could roll and release a Windows binary egg for this?
>
> I just uploaded binary Windows eggs for Python 2.4, 2.5 and 2.6.
Thanks :-)
Chris
--
Simp
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> I mean an index which supplies the 'simple' PyPI interface, such that we
> could tell people to 'easy_install' from it, e.g.:
>
> $ /path/to/bin/easy_install -i http://kgs.zope.org/Zope2/2.1.2
But how do you then set things up when you wa
Roger Ineichen wrote:
> The consequence of fixing versions is to skip backporting.
> There is no way to have both.
Rubbish. Martijn already showed what would need to happen here: the
package specifying the depenedency needs a quick, 3rd point release to
add the backported releases as suitable.
Stephan Richter wrote:
> Updgrading to zope.foo 1.3.x might not be easy for various reasons that I
> think most of us experienced (I know I did). Releasing a new zope.bar version
> might not be possible, if person B does not have access.
If a fix is possible, and someone backports it, a release
Benji York wrote:
> Lets say that someone adds two bug fixes to zope.foo (call them fix A
> and fix B) and then does a release. Fix A requires zope.bar >= 1.5 and
> fix B doesn't. If I want to benefit from fix B in my app (and don't use
> the feature fix A repaired), then I shouldn't be forced to
Martijn Faassen wrote:
> The version requirements in setup.py should always be "open".
>
> The most widely open requirement is this:
>
> zope.foo
>
> but another open requirement is this:
>
> zope.foo >= 1.3
>
> I also don't recall open requirements bringing development to a halt?
>
> I think
Jacob Holm wrote:
>> Can someone confirm to me whether or not manually specifying the context
>> as I have in the example above would work, or would I need to do:
>>
>> >>> adapter1 = getAdapter(a,ISomething,context=siteA)
>> >>> adapter2 = getAdapter(b,ISomething,context=siteB)
>>
> In gener
Christian Theune wrote:
Wichert.
>>> Be aware of nose issue #102:
>>>
>>> http://code.google.com/p/python-nose/issues/detail?id=102
>> Is there a particular reason to keep using the test_suite convention?
>> Personally I much prefer nose's habit of automatically picking up
>> tests.
>
> I t
Hi All (maybe just Jim? ;-) ),
Just did a buildout involving zope.interface and got:
Getting distribution for 'zope.interface'.
WARNING:
An optional code optimization (C extension) could not be compiled.
Dan Korostelev wrote:
> 2009/3/9 Dieter Maurer :
>> Jacob Holm wrote at 2009-3-6 01:55 +0100:
>>> ...
>>> I added it while working for ZC two years ago. It was needed to support
>>> a use case where the context used for looking up the annotation was not
>>> necessarily the current site. I don't kno
Tres Seaver wrote:
>> The reason being that, for a long time, I've wanted to see a persistent
>> registry that stored in a rdb rather than zodb.
>
> I don't know what that would look like.
I have ideas about what I'd like it to look like from a user's
perspective, but sadly not much in the way
Wichert Akkerman wrote:
> I would like to see a move away from zope testing frameworks to a more
> standard testing infrastructure: setup.py test, possibly combined with
> using nose.
I'd love to see a side-by-side feature comparison of the major python
test discovering and runner frameworks. It
Martijn Faassen wrote:
> Thoughts?
+ sys.maxint to all of that from me :-)
I think documenting that something is going to go away is useful, but
ultimately, people only really worry about it when something stops working.
I've got way to bored to the millions of meaningless deprecation
warnings
Hey Tres,
Tres Seaver wrote:
> 2. Move the persistent registry stuff out into another package,
>including whatever support is needed to allow for people to migrate
>existing persistent references. Effectively, this moves one "extra"
>out to a package, *including* its testing dependenc
Martijn Faassen wrote:
> I think we can only make the correct determination if we get an idea of
> the performance implications. If it turns out the C code brings
> significant speedups in real-world applications, we should create a
> zope.hookable with a Python + C implementation.
Even if it
Baiju M wrote:
> I have pasted the relevant code here:
>
> def resolve(self, dottedname):
> """Resolve a dotted name to an object."""
I wonder why zope.dottedname isn't being used here either?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.s
Chris McDonough wrote:
> I believe to get success here (measured as gaining new Python developer
> users),
> our path forward needs to be way, way, way more radical and needs to involve
> making hard choices that treat individual packages on their own merit rather
> than even considering their rol
Dieter Maurer wrote:
> Zvezdan Petkovic wrote at 2009-2-19 13:06 -0500:
>> I can adapt to any style
>> and believe that the fine grain details should not be dogmatically
>> enforced but rather allow for variations in such subjective preferences.
>
> +1
+ sys.maxint
Chris
--
Simplistix - Co
Tres Seaver wrote:
> That is why this is religious: I find "from imports" make code *more*
> readable: the dotted prefixes are "noise" rather than "signal" to my eyes.
+1
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_
Adam GROSZER wrote:
> Someone releases a new package version and your project just break the
> next day. That's a nightmare.
That shouldn't happen with individual package releases where releases
are done sensibly.
(ie: if you're going to do a big backwards-incompatible release, let
people know.
Chris McDonough wrote:
> - discourage the contribution of stop energy (discourage
> the utterances of "don't", "stop", "this is wrong",
Well, unless it is...
> - focusing on externalizing software; each egg should stand on its own as
> something that a non-Zope person would be able to underst
Andreas Jung wrote:
> See this thread:
>
> http://mail.zope.org/pipermail/zope-web/2009-January/thread.html
Shame, oh well, I think dictatorship is the way to go and I think you'd
make a pretty good dictator, so go for it :-)
Chris
--
Simplistix - Content Management, Zope & Python Consulting
Andreas Jung wrote:
> because of the failure of the new.zope.org project I would like to put
> the hat on for reorganizing the Zope 2 presentation on zope.org.
Is this failure official or is there just no action on this?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
Tres Seaver wrote:
>> I guess this equates to "what does a Zope 2 instance look like now that
>> we're buildout-based?"
>
> install_requires=['Zope2>=2.12dev'],
Okay, how do I get zopectl and runzope?
Where do I put my zope.conf?
Where do I put old-school products?
What would the following bu
Tres Seaver wrote:
> At this point, the SVN trunk *is* a buildout:
>
> $ svn co svn+ssh://svn.zope.org/repos/main/Zope/trunk Zope-trunk
> ...
> $ cd Zope-trunk
> $ /oath/to/python2.5 bootstrap.py
> ...
> $ bin/buildout
Another question...
If I have a project that's Zope 2 based, how do I s
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chris Withers wrote:
>> Hanno Schlichting wrote:
>>> I had time to work on this on our Berlinale Sprint and this is now done!
>>>
>>> I marked the old Zope2.buildout area as r
Hanno Schlichting wrote:
> I had time to work on this on our Berlinale Sprint and this is now done!
>
> I marked the old Zope2.buildout area as retired after moving the code,
> so we don't confuse people anymore with two locations doing the same.
Out of interest, where can I learn more about Zope
Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09.02.2009 20:18 Uhr, Hanno Schlichting wrote:
>> Lennart Regebro wrote:
>>> So, I propose to have an Open Space session at PyCon, Chicago, March
>>> 27-29 .
>> Sounds good. Count me in.
>>
>
> Will be there as well.
Me
Adam GROSZER wrote:
> Though no idea how the above could be solved with FOSS tools.
You know Launchpad is being open sourced, right?
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-
Tres Seaver wrote:
> Ugh. -1 to any attempt to use "space suits" in Z2. I would rather move
> to a model which made it easy to mark some / all TTW objects as
> "trusted", disabling security checks altogether: the "untrusted users
> can edit TTW code" use case is pretty much irrelevant for any si
Lennart Regebro wrote:
> On Thu, Jan 22, 2009 at 10:38, Chris Withers wrote:
>>> Note that Jim never explained to me how he does these audits, but I gathered
>>> some methods he used in conversations. I think I did a pretty thorough job
>>> during the review.
>>
Christian Theune wrote:
> It's only a command line option right now.
Which one?
> Making it configurable
> through a buildout option would be nice too.
Yes, so it can live in default.cfg!
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.c
Andreas Jung wrote:
> At least I added a patch to buildout at some time ago in order to
> make the default timeout configurable through a command-line option
> (or was it a buildout options - I can't remember).
Would be good to know where this lives and/or how Christian was limiting
the timeout f
Jim Fulton wrote:
> zope.configuration isn't a namespace package. It is simply a package
> with subpackages.
Does setuptools support something like:
"packagea":
packagea/__init__.py
packagea/amodule.py
"packagea.something":
packagea/__init__.py
packagea/something/__init__.py
packagea/somethin
Dieter Maurer wrote:
> Chris Withers wrote at 2009-1-30 18:50 +:
>> Brian Sutherland wrote:
>>>> zope.configuration.x
>>>> zope.configuration.y
>>> Please don't, having namespace packages that contain files (as
>>> zope.configuration a
Brian Sutherland wrote:
>> zope.configuration.x
>> zope.configuration.y
>
> Please don't, having namespace packages that contain files (as
> zope.configuration already does) breaks setuptools.
Then setuptools needs fixing.
There's no reason why zope.configuration and zope.configuration.x
should
Martijn Faassen wrote:
>>> This makes a lot more sense to me than having the ZCML support in
>>> either zope.component or zope.security.
>> Indeed, surely all zcml stuff belongs in zope.configuration anyway?
>
> No, not there either, as zope.configuration doesn't define *any*
> directives except
Fred Drake wrote:
> On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen
> wrote:
>> I believe it'd be nicer to extract any ZCML related stuff from
>> zope.component at some point and put it into zope.componentzcml or
>> something like that. We could then decide to move the and
>> directives in the
Shane Hathaway wrote:
> Chris Withers wrote:
>> I don't think this is such a huge change, it's a change in the style
>> of what RP does already, not a complete re-implementation...
>
> OTOH, with Python 3 now released, it seems unlikely that we'll see any
&
Dieter Maurer wrote:
> Chris Withers wrote at 2009-1-22 09:38 +:
>> ...
>> One thing that myself and Shane talked briefly about on this list was
>> re-implementing the AST manipulation as dissallow-by-default filter
>> rather than a straight manipulation. That w
Andreas Jung wrote:
>> It's a shame Jim has so little time to spend on this...
>
> Take your hat and collect some money for hiring Jim :-)
Zope Corp chose to assume the Zope brand for themselves, given the
prevelence of Zope 2 and RestrictedPython, it'd be nice if they could
devote some of Jim'
Stephan Richter wrote:
> On Wednesday 21 January 2009, Andreas Jung wrote:
>> - RestrictedPython security audit: such an audit has been made
>> by Stefan and Sidnei. I am not qualified to speak about the
>> correctness of the audit. I assume they know what they were
>> doing. Unless objection
Andreas Jung wrote:
> - - removing ZClasses completely
...into a seperate egg/product, right?
> - - how do to a "traditional" SVN checkout of the Zope 2 and the related
> Zope 3 modules? The Zope2.buildout maintains its dependencies through
> a KGS - the old-style SVN checkout uses svn:exter
Andreas Jung wrote:
> Namespaces are like dust and smoke. We already have enough (pointless)
> namespaces. So let's stick with zope.* and z3c.* for Zope related packages.
Why note merge those two into one then?
Personally, I've always seen zope.* as being usable on their own or with
either Zope
Tim Cook wrote:
> I would also like for you to explain just what it is about my "attitude"
> that you find so offensive/problematic?
As a general rule of thumb, anyone who posts with more than on
exlamation mark is likely on the wrong track.
Cross posting to several lists is also a bit of a no
Hanno Schlichting wrote:
> Community" in its entirety. Inventing a zope2 or z2c namespace is a poor
> choice.
Why? That seems like the perfect namespace for this particular package...
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
__
Alec Mitchell wrote:
>> class IFieldType(Interface):
>> def __call__(self,*args,**kw):
>> r = Interface.__call__(*args,**kw)
>> if r is empty:
>> return None
>> return r
>>
>> I suspect this would work with the python implementation of Interface,
>> but
Shane Hathaway wrote:
> Chris Withers wrote:
>> Now, you could, for example, then do:
>>
>> IFieldType([])
>>
>> ...which should return None.
>
> I don't understand your example: what is a field type,
It's a shortened naem for "Type of
Benji York wrote:
> On Fri, Dec 19, 2008 at 1:03 PM, Chris Withers wrote:
>> Hi Guys,
>>
>> Line 396 of doctest.py contains code which is, at best,
>> platform-specific (and so a bug) or, more likely, irrelevent.
>
> Line 396 of doctest.py from zope.testing 3.
Hedley Roos wrote:
> Chris mentioned unit tests. You do not have to write a new unit test.
> What is required is to have a look at the tests and then identify one
> that is relevant to your problematic method. This test should be very
> easy to read. The "hard" part is for you to expand this test t
Hi Guys,
Line 396 of doctest.py contains code which is, at best,
platform-specific (and so a bug) or, more likely, irrelevent.
I have the following code that runs the tests in all my package's docs:
def test_suite():
suite = unittest.TestSuite()
for path in \
glob(os.path.join(o
Tim Cook wrote:
> As I said before I may have miss-diagnosed the problem and may fix may
> break other things?
This is what a full-coverage unit and functional test suit is for.
You have got automated tests for all this stuff, right?
Chris
--
Simplistix - Content Management, Zope & Python Co
Marius Gedminas wrote:
> doesn't fail with an exception, I can assume that
>
> ISomeInterface.providedBy(adapter)
...which in this case should return True, as None does indeed implement
the interface in question.
>> *That's* what I'm looking for help with, not judgement on whether
>> adaptin
301 - 400 of 2150 matches
Mail list logo
