Hey Martijn,
Any chance on beating on this? Or somewhere else to have a buildbot
slave on win32?
Just touched zc.buildout trunk and it seems to fail miserably on
win32.
Saturday, January 31, 2009, 11:55:47 AM, you wrote:
MF Hi there,
MF Recently there was a project called snakebite revealed:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam GROSZER wrote:
close_fds=True is not supported on win32.
I see that described here:
http://docs.python.org/library/subprocess.html#using-the-subprocess-module
I thought somebody else already took out the 'close_fds' bit.
The biggest
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 think there is not.
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 general, using
Summary of messages to the zope-tests list.
Period Sun Mar 22 12:00:00 2009 UTC to Mon Mar 23 12:00:00 2009 UTC.
There were 6 messages: 6 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Sun Mar 22 21:24:15 EDT 2009
URL:
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 more specific
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
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
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.
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 want
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
--
Simplistix - Content Management, Zope Python
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 that
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
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 benefit
On 3/23/09 12:57 PM, Chris Withers wrote:
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
Previously Chris Withers wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23.03.2009 14:26 Uhr, Wichert Akkerman wrote:
This is an important point. As I see it the KGS is a Zope-only thing,
and is just a workaround for the mindless behaviour of setuptools. I do
not see it gaining acceptance outside of the Zope
On Mon, 2009-03-23 at 14:20 +0100, Wichert Akkerman wrote:
On 3/23/09 12:57 PM, Chris Withers wrote:
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
Previously Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23.03.2009 14:26 Uhr, Wichert Akkerman wrote:
This is an important point. As I see it the KGS is a Zope-only thing,
and is just a workaround for the mindless behaviour of setuptools. I do
not see it
Hi Wichert
Betreff: Re: [Zope-dev] setting missing minimum version in setup.py
Previously Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23.03.2009 14:26 Uhr, Wichert Akkerman wrote:
This is an important point. As I see it the KGS is a Zope-only
Chris Withers wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.:
$ /path/to/bin/easy_install -i
22 matches
Mail list logo