On 11/17/2011 07:01 PM, Martin Aspeli wrote:
I would actually argue that Zope4 have no real release cycle at all:
instead, the individual pieces which make up Zope should have their own
cycles, with perhaps a ZTK-like tracking set that Plone and others use as
platform targets.
-1 - we'll need
Hey,
On 07/11/2011 06:09 PM, Andreas Jung wrote:
According to zope.org Gork is more like ZPT than it is
like BlueBream. Griok is more like CMF than it is like BlueBream. This
is because Grok is listed under the grab-bag framework category.
I partly agree with you - I think Grok can be
On 07/15/2011 03:13 PM, Hanno Schlichting wrote:
On Fri, Jul 15, 2011 at 1:50 PM, Martijn Faassenfaas...@startifact.com
wrote:
I'd just call the category web framework; 2 out of 3 already say they
are. Zope can then itself say in its description that it's an
application server if that's an
Hi there,
Congrats on the relaunch of zope.org, I know it's been a hard slog!
But I brought up an item twice already and nothing appears to have been
done about it. According to zope.org Gork is more like ZPT than it is
like BlueBream. Griok is more like CMF than it is like BlueBream. This
is
On 07/05/2011 12:22 PM, Jonas Meurer wrote:
Since we don't market Zope2 anymore, I think there's actually much
less confusion from this than we'd fear. It's just an internal version
number used in some buildout files, not something that has any
particular meaning.
I don't like either of
Hi there,
On 05/10/2011 06:55 AM, Andreas Jung wrote:
Constructive criticism and feedback is welcome _now_.
Application servers has Zope BlueBream.
Then Grok's at the bottom under 'Frameworks' together with CMF, Repoze,
ZCA, ZTK and ZPT.
Grok is most like BlueBream and should be in a
Hi there,
http://beta.zope.org/the-world-of-zope
dekade - decade:
And just talk about 'Zope community has grown' instead of starting with
Zope Corp. and the Zope community, which I think gives the impression
the community is some kind of appendage to Zope corp, the driving force
behind it
On 03/27/2011 05:13 PM, Martin Aspeli wrote:
On 27 March 2011 15:54, Uli Fouquetu...@gnufix.de wrote:
The (limited) experiences with py.test, however, were awesome. Some
points that are quite cool IMHO:
- Easy finding of tests: just write some ``test_function`` in a
``test_module`` and
On 03/29/2011 02:43 PM, Wichert Akkerman wrote:
On 3/29/11 14:40 , Stephan Richter wrote:
Yeah, Marius led me recently to that path too. Write a narrative in text
files
and use doc strings of functions to do edge cases (or when you don't have
time
for the narrative). I am getting used to
Hey,
[snip Wolfgang]
[1]
http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html
[2] https://github.com/sstephenson/sprockets
Thanks for these links! We should investigate Sprockets to see what
other features it has, and perhaps in the future
Hi there,
[extensive introduction by Uli of zope.pytest]
Thanks Uli for that introduction to the package and its problems!
I've been using zope.pytest within 2 Grok projects so far to test
through webob some JSON webservices, and it's worked well for me. I
hadn't had to deal with the issue of
Hi there,
It is my understanding that the ZTK is primarily to adopt proven
solutions that arise from our community that we intend to be shared by
this community. I'll also note that Martian is already in use in
combination with Bluebream, Zope 2 and Grok.
With that, I was thinking, concerning
Hi there,
For Martian, Python 3 support is mostly an issue of making class
directives work as class decorators.
I'm not sure what Lennart means by point 1.
Anyway, Grok's configuration is dependent on the rules you give it, so
it's possible to have a completely explicit set of directives with
On 03/19/2011 10:02 PM, Lennart Regebro wrote:
Getting ZCA/ZTK to run on PyPy is probably easier, and actually more
useful. Maybe someone would want to mentor that?
I agree it'd be easier and more useful. There's also interesting
potential in exploiting PyPy's magic in things like security and
On 03/20/2011 02:31 PM, Jim Fulton wrote:
On Sat, Mar 19, 2011 at 5:02 PM, Lennart Regebrorege...@gmail.com wrote:
Getting ZCA/ZTK to run on PyPy is probably easier, and actually more
useful. Maybe someone would want to mentor that?
This is another porting project. If I was a student, I
Hi,
On 03/20/2011 03:28 PM, Jim Fulton wrote:
Hm, it's been a while since I've looked at grok. Some notes:
We have more than four years of experience with this topic...
- The mechanism I'm thinking of should not require *any* ZCML.
Check. we just bootstrap the grokking process from ZCML
On 03/21/2011 10:17 AM, Jan-Wijbrand Kolman wrote:
- scanning can take a long time, making application (re)start slow for
non-trivial projects
At what point is an application not trivial anymore? In applications I
build so far, startup time has not been an issue at all. But maybe my
On 03/20/2011 04:29 PM, Jim Fulton wrote:
On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichtingha...@hannosch.eu wrote:
[snip]
I think you cannot avoid this, if you want to support an explicit
configuration phase. Otherwise the first import of a module could
occur at any point at runtime and
Hi there,
On 03/20/2011 04:00 PM, Hanno Schlichting wrote:
Taking one of the examples of grokcore.component, I think there's a
lot that can be made simpler:
import grokcore.component
from zope.i18n.interfaces import ITranslationDomain
class
Hi there,
On 03/20/2011 05:47 PM, Hanno Schlichting wrote:
Maybe there's something in Grok that comes close to this. I've just
not been able to distinguish the Grok the web framework code with
its convention over configuration idea from some basic explicit
configuration approach.
I don't
On 03/21/2011 03:07 PM, Lennart Regebro wrote:
On Mon, Mar 21, 2011 at 14:17, Martijn Faassenfaas...@startifact.com wrote:
Anyway, Grok's configuration is dependent on the rules you give it, so
it's possible to have a completely explicit set of directives with no
implicit fallback to default
On 03/21/2011 03:28 PM, Jim Fulton wrote:
I don't know what the right answer is ... at least not yet. :)
In Django and sqlalchemy declarative a meta class is used for this kind
of configuration. Since that is subclassing, it implies inheritance, I
think.
Of course metaclasses are not very
On 03/21/2011 04:08 PM, Jim Fulton wrote:
On Mon, Mar 21, 2011 at 10:38 AM, Martijn Faassen
faas...@startifact.com wrote:
On 03/21/2011 03:28 PM, Jim Fulton wrote:
I don't know what the right answer is ... at least not yet. :)
In Django and sqlalchemy declarative a meta class is used
Hi there,
On 12/22/2010 09:56 PM, Chris McDonough wrote:
FWIW, for our web stuff I've found PyPy to be about 3X as slow as
CPython (even allowing for the JIT to warm up). But the elephant
dances!
Any clue what's taking up the time? Do you think it's simply that it
doesn't speed up
Hi there,
I thought it'd be interesting to note that PyPy 1.4.1 (with JIT) now
works out of the box with buildout (at least if I use the '-d' option
for distribute with bootstrap.py, but I suspect plain setuptools also
works). I actually added a few compatibility fixes to buildout the other
On 10/13/2010 05:57 PM, Jan-Wijbrand Kolman wrote:
On behalf of the Zope Toolkit release team and the Zope community, I'm
happy to announce the release of Zope Toolkit version 1.0!
Congrats to the ZTK release team!
Regards,
Martijn
___
Zope-Dev
Hi there,
On 09/10/2010 03:04 PM, Hanno Schlichting wrote:
This is unfortunate, but really a problem for the lxml community and
not us. So the lxml community cannot keep up with providing binary
Windows eggs. This cannot force us to stick with old and buggy
versions of the software.
I might
On 07/31/2010 07:22 PM, Jens Vagelpohl wrote:
Here's a followup on a docs.zope.org automation task I took over during
one of the Zope developer IRC metings[1]. The task was to provide
individual package documentation, if it exists, directly underneath
docs.zope.org, e.g.:
On 08/02/2010 05:25 PM, Jens Vagelpohl wrote:
python setup.py --long-description
Can someone tell me how to do that when I am in Python code already?
Given the path to the checkout, can I use some setuptools/pkg_resources
or pkginfo magic to get at this data?
Oh, this is where I always get
On 08/02/2010 06:34 PM, Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/2/10 18:26 , Martijn Faassen wrote:
http://packages.python.org/distribute/pkg_resources.html
You can probably create a Distribution object somehow (handwave) from a
path (whether that's
On 07/13/2010 02:12 PM, Hanno Schlichting wrote:
Given all of these, I'm leaning towards not supporting Python 2.7 for
a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to
support 2.7 in addition.
+1
For Zope standards we'd still be very fast with supporting Python 2.7 if
Hey,
[zope.traversing absolute URL behavior]
I've applied the fix to zope.traversing and added a test as well. It's
released as zope.traversing. I've also updated the ZTK to use this version.
(initially I used checkversions to update a few other packages too,
namely zope.dublincore,
On 07/09/2010 04:50 PM, Hanno Schlichting wrote:
I noticed that all three frameworks (BB, Grok, Zope2) have version
pins for Paste, PasteDeploy and PasteScript. Does anyone object to
including them into the ztk-versions.cfg under dependencies?
No objections from Grok.
Regards,
Martijn
Hi there,
I've been waiting for years for a release of buildout that contains
proper isolation from Python's site-packages. The non-isolation is a
major flaw in buildout that makes it SO much harder to write proper
installation instructions for software such as Grok.
We need to wrap Grok's
Hi there,
I was told to ask this question on distutils-devel, which I recall is
the proper list for buildout related discussions. See you there.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hi there,
It appears that Grok 1.1 doesn't send error messages to the terminal by
default? This is really inconvenient and I wonder what change broke it.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
On 07/08/2010 03:36 PM, Martijn Faassen wrote:
Hi there,
It appears that Grok 1.1 doesn't send error messages to the terminal by
default? This is really inconvenient and I wonder what change broke it.
Argh, wrong mailing list, sorry.
Regards,
Martijn
Hi there,
in zope.traversing.browser.absoluteurl there was a change a while back
that breaks my code, now that I'm upgrading to it.
The code in the absolute URL generation code used to be this:
container = getattr(context, '__parent__', None)
This simply gets the __parent__ of the
On 07/05/2010 08:56 PM, Sidnei da Silva wrote:
On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassenfaas...@startifact.com
wrote:
(But hurry.resource is not perfect; I think it'd be better to step out
of Python land and create a Javascript packaging system somewhat modeled
on Python's, with easy
On 07/05/2010 09:32 PM, Jim Fulton wrote:
On Mon, Jul 5, 2010 at 2:56 PM, Sidnei da Silva
sidnei.da.si...@canonical.com wrote:
On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassenfaas...@startifact.com
wrote:
(But hurry.resource is not perfect; I think it'd be better to step out
of Python land
On 07/06/2010 09:46 AM, Wichert Akkerman wrote:
On 2010-7-5 23:08, Hanno Schlichting wrote:
Hi there,
with Python 2.7 final being released, I ran the ZTK tests against it.
zope.exceptions, zope.formlib and zope.proxy all have one test output
related failure.
We seem to have a lot of
Hey,
On 07/06/2010 01:04 PM, Charlie Clark wrote:
In the specific zope.formlib test we have a doctest
embedded within another:
MyForm(None, request)() # doctest: +NORMALIZE_WHITESPACE +ELLIPSIS
There were errors:
(u'Invalid floating point data',
On 07/06/2010 01:27 PM, Charlie Clark wrote:
Am 06.07.2010, 13:12 Uhr, schrieb Martijn Faassenfaas...@startifact.com:
What do you mean, a doctest embedded within another? I'm probably
missing something.
No, it's probably me getting the explicit doctest call wrong. It looks to
my novice eyes
On 07/06/2010 05:00 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fred Drake wrote:
On Wed, Jun 30, 2010 at 3:47 PM, Hanno Schlichtingha...@hannosch.eu wrote:
On behalf of the Zope Toolkit release team and the Zope community, I'm
happy to announce the first 1.0 alpha
Hi there,
Thanks for kicking off this discussion, here's my old grump response. :)
On 06/29/2010 05:24 PM, Hanno Schlichting wrote:
- Agree on a process for larger feature changes in Zope. Things like
zope.publisher vs. WSGI, changes to zope.interface semantics, security
without proxies, the
Tres Seaver wrote:
python 2.5 and 2.6 :
- zope.app.wsgi
I plan to work on fixing this failure, which is due to moving the
zope.testbrowser pin from 3.8.2 to 3,9.1.
How are you going to fix it? I'm asking because we depend on
zope.app.wsgi for the browser testing of Grok now, at least on a
Hanno Schlichting wrote:
- Look at Tres's list of packages in all three frameworks, decide on a way to
drop things from the initial ZTK set and on a process for the future.
As long as things are not dropped immediately. Even though Grok 1.2
might not need foo.bar, transition support might
Tres Seaver wrote:
Vincent Fretin wrote:
If I followed the commits correctly, the mkzeoinst was extracted from
ZODB3 package and is now in the zope.mkzeoinstance, right?
Yes. I was questioning why a ZTK user, rather than somebody using an
appserver like Zope2, etc., would need a
Tres Seaver wrote:
BlueBream or grokproject, which generate code to set up applications,
might want to pull it in (or emit the depenency into the generated
code). Zope2 definitely needs it.
If it's sensible for all three projects to use it I think it makes sense
for it to be in the ZTK. Even
Hanno Schlichting wrote:
Dropping Python 2.4 supports makes most sense to me at this stage.
Zope2/Plone only support Python 2.6 for any modern version.
I don't know what BlueBream and Grok want to support, but would guess
they aim for Python 2.5 + 2.6 support. 2.4 is really old by now.
Grok
Hi there,
Wouldn't it be useful to add the reports of the weekly IRC meetings to
the ZTK docs? This way we have an archive that includes some decisions
and such that's easier to go through than the mailing list archive. It
also provides a source of information that could then later be
Charlie Clark wrote:
I think some kind of paper trail is definitely a good idea. Not sure if
docs is the right place but Christian is planning to put the reports into
the svn repository. And both location and form are less important than
having an archive*. We'll have something sorted by
Lennart Regebro wrote:
I thought it was painless already, but maybe I was wrong. :)
It's very nice to be able to do a full release by just typing
'fullrelease' and saying 'yes' a number of times. The tool made a
convert out of me, and I know others who also were pleased by how much
it sped
Vincent Fretin wrote:
For the tool, I think I did it already. I modified one of Hanno's
script some times ago:
cd zopetoolkit/trunk
bin/buildout -c checknew.cfg
bin/python checknew.py
Cool! This tool should be documented if it isn't already.
Why is this in a separate .cfg unlike the other
Hanno Schlichting wrote:
Good evening :)
If you have a specific issue with me, you might contact me in private.
But with your follow-ups this turned into a more general issue.
No, I think this needs to be public as the ZTK is a public project that
I care about. And you're not playing your
Hi there,
Hanno Schlichting wrote:
I expect us to define the process around package releases and updating
the ZTK. It's not entirely clear to me who should and who is allowed
to update the ZTK definition. We'll figure things out and once we have
I'll stick to the rules.
My few cents:
I
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This
has all been discussed too often already.
As far as I know, I've *never* discussed this fork on this list, but I
might be wrong; feel free to dig the archives. But that doesn't matter:
the fork is
Wichert Akkerman wrote:
I suggest that we wait impatiently for the ZTK steering committee to
come up with a useful policy instead of trying to do their work when
none of us volunteered for the task.
I don't understand your suggestion. Could you rephrase it?
I'm a ZTK user, and I'm
Martijn Faassen wrote:
[snip]
Why is this in a separate .cfg unlike the other tools that come with the
ZTK? Unless creating this extra script is very expensive, I think it
makes sense to generate it in 'bin' along with the rest of the scripts.
To expand on that, it'd be nice if it were also
Wichert Akkerman wrote:
On 5/3/10 12:51 , Martijn Faassen wrote:
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This
has all been discussed too often already.
As far as I know, I've *never* discussed this fork on this list, but I
might be wrong
Wichert Akkerman wrote:
On 5/3/10 12:52 , Martijn Faassen wrote:
Wichert Akkerman wrote:
I suggest that we wait impatiently for the ZTK steering committee to
come up with a useful policy instead of trying to do their work when
none of us volunteered for the task.
I don't understand your
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now
defunct ZTK steering group,
If it's defunct someone better update the documentation.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hi there,
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a handy summary:
* please construct guidelines for updating the ZTK when making a release
of a package that's managed by the ZTK project. It's useful people
test
Lennart Regebro wrote:
On Mon, May 3, 2010 at 13:22, Martijn Faassen faas...@startifact.com wrote:
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now
defunct ZTK steering group,
Well, if it's defunct or not is up to the members of the steering
Hanno Schlichting wrote:
Hi Martijn,
On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com
wrote:
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a handy summary:
Thank you very much for your
Lennart Regebro wrote:
On Mon, May 3, 2010 at 15:41, Martijn Faassen faas...@startifact.com wrote:
Well, I'm disappointed in the zope documentation process then. Work faster!
:)
If you don't inform people about this release manager team thingy, you
can't rightly expect people like me
Hi there,
On Mon, May 3, 2010 at 6:06 PM, Lennart Regebro rege...@gmail.com wrote:
I don't know anything about the fork, but my view of the fork is that
of Hanno wants a fork, Hanno can have a fork, as long as he doesn't
try to poke anyones eye out with it. If it's a stupid waste of time,
Hi there,
On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro rege...@gmail.com wrote:
On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@startifact.com wrote:
Hanno is making releases of packages in the ZTK. So it's not just
Hanno's waste of time; it's mine too.
Obviously he shouldn't hurt
Hi there,
Tres Seaver wrote:
One issue with insta-updates to ztk.cfg is that ongoing development of a
package can be in real tension with the needs of ZTK consumers for
stability in the package set.
Since there are no ZTK releases Grok and BlueBream gain stability by
pinning to a
Hey,
Tres Seaver wrote:
[snip]
I expect to see Zope2 trunk move to using the ZTK versions list quite
soon: more than that, I'm willing to to the work to see that it happens
(verifying that everything passes / works with the change), and give
Hanno the patch to make it so, assuming he doesn't
Charlie Clark wrote:
FWIW this is a very poor
strategy to win people over to your point of view.
I'm not trying to win over people to my point of view. I tried that last
year, but people just forked when they couldn't work it out with me.
I've learned that rash actions without consideration
Lennart Regebro wrote:
On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote:
Since there are no ZTK releases Grok and BlueBream gain stability by
pinning to a particular revision of ztk.cfg (and moving it forward when
needed). Zope 2 could easily do the same. If more
Hi there,
On Mon, May 3, 2010 at 10:26 PM, Hanno Schlichting ha...@hannosch.eu wrote:
On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@startifact.com
wrote:
Last december Hanno made progress on the ZTK's dependency structure,
removing a lot of dependencies on packages. In his
Hey,
Christophe Combelles wrote:
Thanks for these suggestions. This is *exactly* what we (the ztk
release team) need.
How wonderfully diplomatic and constructive, my compliments! The
release team (you, Hanno and JW) look good to me.
* please let these guidelines not block most updates by
Hi again,
One more suggestion I can make is a way to get an integrated changelog
for lists of packages such as the ZTK. Right now it's hard to track what
kind of changes there have been in the ZTK as a whole; you have to go
through all packages. If there were a way to generate a unified
Hi there,
I saw a zope.exceptions release on pypi, but it has no release date is
marked in its change log:
http://pypi.python.org/pypi/zope.exceptions/3.6.0
I recommend following the procedure to avoid such issues:
http://docs.zope.org/zopetoolkit/process/releasing-software.html
I highly
Hi there,
Hanno, can you please update the zopetoolkit and do tests there as well
when you make releases of packages maintained by the Zope Toolkit
project? Because otherwise you're just wasting my time trying to sync
things up again, and that's annoying.
Not annoying me is one good reason,
Hi there,
Of course what applies to Hanno should apply to others making releases
of packages maintained by the Zope Toolkit project as well. I think the
ZTK leadership should figure out some kind of guidelines for this that
people can follow. Maybe someone can write a tool too to check up how
Hi there,
Martijn Faassen wrote:
Of course what applies to Hanno should apply to others making releases
of packages maintained by the Zope Toolkit project as well. I think the
ZTK leadership should figure out some kind of guidelines for this that
people can follow. Maybe someone can write
Hi there,
Two typos in the title, maybe I'm turning into Jim. :)
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
Stephan Richter wrote:
On Monday 26 April 2010, Martijn Faassen wrote:
Could someone give me and Hanno pypi access to zope.browserresource and
zope.browsermenu?
I am in the process to give you access to all the packages that I am an owner
of (now that PyPI is fixed again. :-)
Let me
Hi there,
Tres Seaver wrote:
Martijn Faassen wrote:
Interesting, and thanks for doing this. Concerning Grok, did you look at
Grok 1.0 or Grok 1.1?
Just grok/trunk (I was trying to think about the state of ZTK in terms
of how it was being used by latest-and-greatest versions
Hi there,
Could someone give me and Hanno pypi access to zope.browserresource and
zope.browsermenu?
Our pypi usernames are:
faassen
hannosch
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Interesting, and thanks for doing this. Concerning Grok, did you look at
Grok 1.0 or Grok 1.1?
For Grok 1.2 we've identified that the following zope.app packages are
certainly used:
* zope.app.wsgi
* zope.app.appsetup
* zope.app.publication
We've eliminated the dependencies of these
Hi there,
Chris McDonough suggests to ponder further structuring of the ZTK into
separate sub-sets which might allow us to get better mileage regarding
maintenance and release management. He gave the example of the
Bicycle Toolkit (zope.component, zope.configuration,
zope.interface).
Hi there,
I've said my piece. I'm not going to argue about it.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
Hi there,
This is to announce my withdrawal from the Zope Toolkit steering
group.
I withdraw from the Zope Toolkit steering group for two reasons:
* The steering group is not working as a group. Most steering group
members haven't been doing much steering. This left me by myself to
try to
robert rottermann wrote:
[snip]
all the other items bear so little market value that even an insider can not
place them.
Therefore I think either of the two should be part of any new packages name
meant to be recognized by non Zope affectionados.
Bluebream for Zope
I've sometimes called
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the support
for
Python 2.4 was dropped, so I can't upgrade to the current ZTK.
This is a surprise to me. I thought we still supported Python 2.4
Regards,
Martijn
Hi Tres,
You don't seem to get what I kept telling you over and over. I'm
therefore going to be more blunt.
I don't want to use zope.app packages in Grok. Grok wants to get rid of
zope.app packages. That's the very idea. We pushed this from the start.
I spent a huge amount of time to make
Hermann Himmelbauer wrote:
Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the
support for Python 2.4 was dropped, so I can't upgrade to the current
ZTK.
This is a surprise to me. I thought
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hermann Himmelbauer wrote:
Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver:
Martijn Faassen wrote:
Obviously I cannot *force* ZTK
maintainers to worry about this. Instead I'm appealing to your
self-interest
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey Tres,
Tres Seaver wrote:
You're kidding, right?
[snip]
My self-interest? Not really: you are appealing to my altruism, in the
fact that I care about the *broader* Zope community (broader
Martijn Faassen wrote:
[snip]
But I do see that Python 2.4 has a failed test, so we do need to fix that.
Some of those failure appears to be because some code was switched over
to the Python standard library pprint from the version in zope.testing,
and in Python 2.4 that doesn't sort
Martin Aspeli wrote:
Martijn Faassen wrote:
Instead, we had endless debates about whether it was a legitimate
concern for the ZTK maintainers. I'm of course still right that it is.
I have wonderful and coherent reasons to support my position just like
everybody else does who disagrees
Martijn Faassen wrote:
[snip]
So how can we have better discussions?
We can have better discussions by helping me.
How can you help me? Of course it helps if you agree with me. I realize
that's frequently infeasible, but I certainly wouldn't mind. :)
If you disagree with me, I'd like
Martijn Faassen wrote:
It seems to be occurring somewhere in the setup of the test layer, but
strangely enough the publisher kicks in somewhere. I'm curious why the
ZTK tests didn't catch this issue (or now the zopeapp tests).
Hm, the zopeapp tests are catching this today. They weren't
Hi there,
25 zope.app packages are broken due to changes in zope.publisher 3.12.
zope.publisher had some components factored out of it into zope.login.
I fixed zope.app.exception: it could be fixed by adding the zope.login
requirement and adding a zcml include statement. I suspect most,
Hanno Schlichting wrote:
On Mon, Jan 4, 2010 at 11:51 PM, Martijn Faassen faas...@startifact.com
wrote:
Good news, it was only 24 packages, I counted wrong. :)
Couldn't you have solved that by updating one underlying package, like
zope.app.testing? Most of zope.app generally depends
Lennart Regebro wrote:
[snip]
Also if the above code is deemed as being a Good Idea, I will remove
all the usage of zope.testing.doctest from Manuel. This is necessary,
as one of the things I need from Manuel is a Python 3 port, and I'm
not porting zope.testing.doctest to Python 3.
I think
1 - 100 of 1200 matches
Mail list logo
