Hi,
On 07/01/2009 11:12 AM, Jim Fulton wrote:
[...]
You can specify include and exclude options; the default is to
include a
list of zope.* packages that we pulled out of thin air at the sprint,
it'd probably be better to use the KGS as a default instead -- but
that
would duplicate even
On Tue, 2009-06-30 at 14:35 -0400, Tres Seaver wrote:
While I know that Mac people often report problems building lxml, I
never have issues building lxml on Linux: the '--static-deps' option is
a sufficient workaround for variants with too-old versions of libxml2 /
libxslt.
I do not know
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Cook wrote:
On Tue, 2009-06-30 at 14:35 -0400, Tres Seaver wrote:
While I know that Mac people often report problems building lxml, I
never have issues building lxml on Linux: the '--static-deps' option is
a sufficient workaround for
On Wed, Jul 1, 2009 at 7:08 AM, Wolfgang Schnerringw...@gocept.com wrote:
I think it would be useful to standardize on *one* compatibility testing
method for the ZTK (and then document it).
I think it would be good if someone actually would define what the ZTK
includes in terms of packages ;)
On Jun 30, 2009, at 2:41 PM, Tres Seaver wrote:
...
IMO, Any ZTK package should be testable via plain 'python2.{5,6}
setup.py test'. If that doesn't get the testing dependencies
installed,
then they should be added.
There is a recipe for testing *other* packages which might be affected
On Jul 1, 2009, at 1:08 AM, Wolfgang Schnerring wrote:
* Tres Seaver tsea...@palladion.com [2009-06-30 20:41]:
Jim Fulton wrote:
I should know this, but I don't. What is the recommended way to
test
changes to core ZTK packages to mitigate the risk that changes
affect
other packages?
On Jul 1, 2009, at 1:08 AM, Wolfgang Schnerring wrote:
* Tres Seaver tsea...@palladion.com [2009-06-30 20:41]:
Jim Fulton wrote:
I should know this, but I don't. What is the recommended way to
test
changes to core ZTK packages to mitigate the risk that changes
affect
other packages?
On Jun 30, 2009, at 7:25 PM, Stephan Richter wrote:
Given that this locks down versions, wouldn't it make more sense to
not check in configurations with failing (or hanging) tests?
That's probably not a bad idea. I think we should make that a rule.
So, I wonder if there is a previous
Wichert Akkerman wrote:
On 6/30/09 7:03 PM, Stephan Richter wrote:
It is needed for the latest-versions script as this parses XML. I consider
lxml pretty much the standard tool to do XML in Python these days. Who is not
using lxml?
I suspect the majority of people who use OSX as their main
On Jun 30, 2009, at 10:14 AM, Stephan Richter wrote:
On Tuesday 30 June 2009, Jim Fulton wrote:
I should know this, but I don't. What is the recommended way to test
changes to core ZTK packages to mitigate the risk that changes affect
other packages? Is there a page somewhere with
On Jul 1, 2009, at 1:42 PM, Stephan Richter wrote:
On Wednesday 01 July 2009, Jim Fulton wrote:
What is the difference between zope.release and zope.kgs? Is the
latter a fossil? Does it need to go away?
zope.kgs is the software and zope.release is the management of the
Zope 3 KGS.
So a
I should know this, but I don't. What is the recommended way to test
changes to core ZTK packages to mitigate the risk that changes affect
other packages? Is there a page somewhere with instructions?
I tried using using zope.release. Building the trunk of zope.release
with Python 2.4 and
I have to chime in here too
lxml is a real pain and seems to be problematic to get a straightforward
build for packages other than ZTK as well. I have had varying success
building lxml even under ubuntu - success seems to be dependant on the type
of build defined.
T
On Tue, Jun 30, 2009 at
On Tuesday 30 June 2009, Jim Fulton wrote:
I should know this, but I don't. What is the recommended way to test
changes to core ZTK packages to mitigate the risk that changes affect
other packages? Is there a page somewhere with instructions?
I tried using using zope.release. Building
On 6/30/09 7:03 PM, Stephan Richter wrote:
It is needed for the latest-versions script as this parses XML. I consider
lxml pretty much the standard tool to do XML in Python these days. Who is not
using lxml?
I suspect the majority of people who use OSX as their main platform try
to stay as
On Jun 30, 2009, at 1:03 PM, Stephan Richter wrote:
I consider
lxml pretty much the standard tool to do XML in Python these days.
I don't want to diss lxml, but since it's not in the standard library,
I imagine far more people use element tree.
Who is not
using lxml?
I don't. I don't do
On Jun 30, 2009, at 1:03 PM, Stephan Richter wrote:
...
2. Run python bootstrap.py
Which Python? 2.4, 2.5, 2.6? All of the above?
Jim
--
Jim Fulton
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
Can't use lxml on google app engine either.
I use ElementTree. If only the lxml extensions to the etree API were
available in ElementTree, especially the ability to pretty print the
xml and do xpath queries, that would be great.
On Tue, Jun 30, 2009 at 7:25 PM, Jim Fultonj...@zope.com wrote:
On Tuesday 30 June 2009, Jim Fulton wrote:
On Jun 30, 2009, at 1:03 PM, Stephan Richter wrote:
...
2. Run python bootstrap.py
Which Python? 2.4, 2.5, 2.6? All of the above?
I have mainly run test under 2.5. I am fine if people run those tests after
changes in any Python version. ;-)
Of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Hoffman wrote:
I have to chime in here too
lxml is a real pain and seems to be problematic to get a straightforward
build for packages other than ZTK as well. I have had varying success
building lxml even under ubuntu - success seems to be
On Jun 30, 2009, at 1:03 PM, Stephan Richter wrote:
...
I am running the tests as I am writing this. So far I got one failure:
Traceback (most recent call last):
File /opt/zope/packages/eggs/z3c.macro-1.2.1-py2.5.egg/z3c/macro/
tests.py,
line 29, in module
import z3c.pt
ImportError:
On Jun 30, 2009, at 1:04 PM, Stephan Richter wrote:
On Tuesday 30 June 2009, Stephan Richter wrote:
I'll report the full output when it is done.
And here it is.
OK, this sorta looks like what I got with Python 2.4. It probably
would have been good enough to say yeah, I get lots of
On Tuesday 30 June 2009, Jim Fulton wrote:
And here it is.
OK, this sorta looks like what I got with Python 2.4. It probably
would have been good enough to say yeah, I get lots of errors too. :)
Sorry! ;-)
So basically, this is how we're supposed to run tests and we're in
bad shape,
* Tres Seaver tsea...@palladion.com [2009-06-30 20:41]:
Jim Fulton wrote:
I should know this, but I don't. What is the recommended way to test
changes to core ZTK packages to mitigate the risk that changes affect
other packages? Is there a page somewhere with instructions?
I tried
24 matches
Mail list logo
