Hey,
Roger Ineichen wrote:
I think there is a little confusion about which package depends on
each other.
Right now there is a zmi.core package this package should
contain core parts without to much dependency. After that
we need several zmi.* packages which are replacements for
each
Am 12.04.2009 um 15:12 schrieb Michael Howitz:
Hi,
I'm using a trunk version of z3c.form and have the following
situation:
In my interface I have a zope.schema.Bytes field.
z3c.form.converter.FileUploadDataConverter.toFieldValue returns
z3c.form.interfaces.NOT_CHANGED when I do not upload
Summary of messages to the zope-tests list.
Period Tue Apr 21 12:00:00 2009 UTC to Wed Apr 22 12:00:00 2009 UTC.
There were 8 messages: 8 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Tue Apr 21 20:45:33 EDT 2009
URL:
Michael Howitz wrote:
Am 12.04.2009 um 15:12 schrieb Michael Howitz:
Hi,
I'm using a trunk version of z3c.form and have the following
situation:
In my interface I have a zope.schema.Bytes field.
z3c.form.converter.FileUploadDataConverter.toFieldValue returns
Hi,
On Tue, 21 Apr 2009 18:40:51 +0200
Martijn Faassen faas...@startifact.com wrote:
Or should we break BBB and let people know that they have to install
zmi.core for zmi support? (I think so)
I won't break BBB as much as possible, at least I'd like to keep persistent
data
Hi,
On Wed, 22 Apr 2009 09:48:40 +0200
Martijn Faassen faas...@startifact.com wrote:
Hey,
Roger Ineichen wrote:
I think there is a little confusion about which package depends on
each other.
Right now there is a zmi.core package this package should
contain core parts without to
Hey,
Yusei TAHARA wrote:
[snip]
BTW, what do you think of zope.app.form? As far as I know, it has some
basic interfaces like IInputWidget and IDisplayWidget, and they are used
by various packages. Then I don't see any reason to leave them under
zope.app.form. So, I think maybe we could also
I want to suggest two changes to the standard release process:
1. use sdist --formats=zip. This works around a nasty bug in the
python 2.4 tarfile module which makes it skip files with a
path of a specific length. This can make a release impossible to use.
2. forbid the use of __file__ in
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman wich...@wiggy.net wrote:
I want to suggest two changes to the standard release process:
1. use sdist --formats=zip. This works around a nasty bug in the
python 2.4 tarfile module which makes it skip files with a
path of a specific length.
Previously Benji York wrote:
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman wich...@wiggy.net wrote:
I want to suggest two changes to the standard release process:
1. use sdist --formats=zip. This works around a nasty bug in the
python 2.4 tarfile module which makes it skip files
On 4/22/09 4:57 PM, Jim Fulton wrote:
Perhaps you could provide (or point to) an example that illustrates
this problem.
I want to keep my python install clean, so I do not have setuptools
installed system-wide. Instead I have a small bin-directory managed by
buildout which creates a python
On Wed, Apr 22, 2009 at 10:55 AM, Wichert Akkerman wich...@wiggy.net wrote:
Previously Benji York wrote:
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman wich...@wiggy.net wrote:
I want to suggest two changes to the standard release process:
1. use sdist --formats=zip. This works around
Previously Benji York wrote:
On Wed, Apr 22, 2009 at 10:55 AM, Wichert Akkerman wich...@wiggy.net wrote:
Previously Benji York wrote:
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman wich...@wiggy.net
wrote:
I want to suggest two changes to the standard release process:
1. use
On Apr 22, 2009, at 11:01 AM, Wichert Akkerman wrote:
On 4/22/09 4:57 PM, Jim Fulton wrote:
Perhaps you could provide (or point to) an example that illustrates
this problem.
I want to keep my python install clean, so I do not have setuptools
installed system-wide. Instead I have a
Hi!
After 8-9 years of admiring Zope and using it now and then, I
finally got myself to contribute to the grok project. I hope to
contribute even more in the near and mid-term future.
We seem to have an issue with the documentation for becoming an SVN
Contributor. Here are the steps I
Hey,
Benji York wrote:
[snip]
Maybe we should officially drop 2.4 support instead.
I'm +1 on dropping 2.4 support for new releases of Zope Toolkit
packages. As soon as Grok 1.0 is released I'm fine with dropping support
for 2.4 in future releases of Grok as well.
Of course we do still have
Wichert Akkerman wrote:
2. forbid the use of __file__ in setup.py. This breaks on systems
which do not have setuptools installed globally but rely on a
(zc.buildout-created) wrapper script. __file__ will point
to the wrapper script in those instances, which breaks setup.py.
This
Hey,
Wichert Akkerman wrote:
[snip]
Unfortuantely there is a large group of people using Plone on Zope 2.10
who can not upgrade to a newer python version, and they are very
interesting in the Zope Toolkit candy.
Are Zope 2.10 users interested in using *recent* releases of the Zope
Toolkit
Hey Behrang,
Andreas Jung wrote:
[snip]
http://docs.zope.org/developer/becoming-a-contributor.html
That's the new location.
It's bad when people's messages are held in the mail queue. My apologies
Behrang, that's of course not good. Thanks also for bringing this to our
attention to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
Unfortuantely there is a large group of people using Plone on Zope 2.10
who can not upgrade to a newer python version, and they are very
interesting in the Zope Toolkit candy.
They shouldn't be: there is no way we are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 22.04.2009 um 17:42 schrieb Martijn Faassen:
Hey,
Wichert Akkerman wrote:
[snip]
Unfortuantely there is a large group of people using Plone on Zope
2.10
who can not upgrade to a newer python version, and they are very
interesting in the
On Sun, Apr 19, 2009 at 16:33, Tres Seaver tsea...@palladion.com wrote:
Supported, documented and recommended installation methods should be
- zc.buildout (working)
- virtualenv + easy_install (see above)
Can we use the 'versions*.cfg' files to automate creation of the index
at
Previously Martijn Faassen wrote:
Wichert Akkerman wrote:
2. forbid the use of __file__ in setup.py. This breaks on systems
which do not have setuptools installed globally but rely on a
(zc.buildout-created) wrapper script. __file__ will point
to the wrapper script in those
Martijn Faassen wrote:
This will break many setup.py scripts that use __file__ to integrate
README.txt and such for publication on pypi. I think that's a useful
feature we cannot just drop, so hopefully there's another solution.
Yeah, I do this a lot *and* use buildout so don't have
Wichert Akkerman wrote:
Can we assume that the cwd is the root of the package?
You can assume whatever you like, the problem is when other people
assume something different ;-)
There's no *need* to make this assumption...
Chris
--
Simplistix - Content Management, Zope Python Consulting
On 4/22/09 4:13 PM, Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
Wichert Akkerman wrote:
2. forbid the use of __file__ in setup.py. This breaks on systems
which do not have setuptools installed globally but rely on a
(zc.buildout-created) wrapper script. __file__ will
Folks,
Stop talking about this. :)
This is almost certainly a buildout bug that I'll fix.
Jim
On Apr 22, 2009, at 5:40 PM, Chris McDonough wrote:
On 4/22/09 4:13 PM, Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
Wichert Akkerman wrote:
2. forbid the use of __file__ in
Hi Martijn
Betreff: Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hey,
Roger Ineichen wrote:
I think there is a little confusion about which package depends on
each other.
Right now there is a zmi.core package this package should
contain core
parts without to much
28 matches
Mail list logo
