Brandon Craig Rhodes wrote:
Tres Seaver [EMAIL PROTECTED] writes:
Martijn Faassen wrote:
IFoo.adapt() for normal adaptation
IFoo.multiadapt() for multi adaptation
I'd rather have 'adapt' take *args for the contexts, and keywords
for extras (like name).
And you could make the default=
On 2007-09-26 17:30:21 +0200, Stephan Richter
[EMAIL PROTECTED] said:
On Wednesday 26 September 2007 11:23, Christian Zagrodnick wrote:
Ok. Would this break anything when z3c:template suddenly uses a
different interface?
I don't think so, because this is not used in Python code usually.
Am 27.09.2007 um 05:35 schrieb Stephan Richter:
On Wednesday 26 September 2007 09:06, Michael Howitz wrote:
This solution requests that the back-end supports non-optimistic
save-points. But we can get rid of the Data class.
We'll start an implementation of the second approach on a branch
On 27 Sep 2007, at 02:29 , Tres Seaver wrote:
Further, anybody who finds the effort of creating a fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the release manager pool.
I'm *not* kidding about that: taking shortcuts durng the release
**sigh**
this morning i replaced the faulty *.zip eggs with new tar.gz releases:
- zope.app.applicationcontrol
- zope.app.appsetup
- zope.app.session
- zope.app.error
- zope.error
in case there are some other .zip eggs in the wild - please fix them
asap.
i don't blame anyone for releasing
On 27 Sep 2007, at 04:52 , Stephan Richter wrote:
On Wednesday 26 September 2007 20:35, Tres Seaver wrote:
So I usually create the release first and upload it and after
that create
the tag.
-100. Get it right, check it in, *then* upload the distribution.
We do not have the tools. There
On Thursday 27 September 2007 05:02, Jodok Batlogg wrote:
this morning i replaced the faulty *.zip eggs with new tar.gz releases:
They are not faulty!! There is a bug in distutils and a fix has been done in
setuptools yesterday.
Regards,
Stephan
--
Stephan Richter
CBU Physics Chemistry
On Thursday 27 September 2007 05:14, Philipp von Weitershausen wrote:
There is some telling beforehand:
* As I already said, you can generate all the package metadata with
python setup.py egg_info
and then inspect it in src/EGG.egg-info/PKG-INFO. This is
equivalent to checking
Hey,
On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
Further, anybody who finds the effort of creating a fresh' checkout
bevore making a release too burdensome should consider themselves
self-selected out of the release manager pool.
I'm *not* kidding about that: taking shortcuts
Hey,
I think that replacing 'index_url' with a gated community of packages
is the only path to sanity here: the contract of the Cheeseshop (share
new releases of all packages with everyone ASAP) is incompatible with
our goals (ensure that users can install a given package and its
Hey,
Tres Seaver wrote:
[snip]
I think that replacing 'index_url' with a gated community of packages
is the only path to sanity here: the contract of the Cheeseshop (share
new releases of all packages with everyone ASAP) is incompatible with
our goals (ensure that users can install a given
Philipp von Weitershausen wrote:
On 27 Sep 2007, at 13:07 , Martijn Faassen wrote:
[snip]
Let's focus on the reasons for each step and keep the discussion at
that level, please? I think it's useful if people ask is that really
necessary? for steps in the release process. Just weigh the pros
On 27 Sep 2007, at 12:20 , Stephan Richter wrote:
egg_info does not validate the trove classifiers, for example. I
tried this
last night before writing this mail.
Well, to be honest, I wonder how you can mess up with the
classifiers. I just always copy them from
Hi there,
While Jim expected to see some form of fireworks in the distutils
discussion that I started about the requirement to pin down eggs while
still leaving flexibility for those who want it, I think we've come to
an early conclusion.
Philip Eby responded and said that my use cases
On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote:
These are four separate cases where I've actually witnessed myself or
other people mess up. We're forgetful, we can't do anything about
that. We can, however, force us to catch our mistakes. I believe that
if we made
Hey,
On 9/27/07, Stephan Richter [EMAIL PROTECTED] wrote:
On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote:
[snip]
A fairly simple tool can find and report all the problems found and offer
assistance. I think it is worth investing in one, especially since it will
reduce my
On 27 Sep 2007, at 13:47 , Stephan Richter wrote:
On Thursday 27 September 2007 07:18, Philipp von Weitershausen wrote:
These are four separate cases where I've actually witnessed myself or
other people mess up. We're forgetful, we can't do anything about
that. We can, however, force us to
Philipp von Weitershausen wrote:
On 27 Sep 2007, at 13:47 , Stephan Richter wrote:
On Thursday 27 September 2007 07:18, Philipp von Weitershausen
wrote:
These are four separate cases where I've actually witnessed
myself or other people mess up. We're forgetful, we can't do
anything about
Hi,
Zagy and I are trying to make z3c.form compatible with sources. We had
to investigate zope.schema for that and found the mess of vocabularies
and sources that is still around.
Here are some facts we found:
- The Choice field has an attribute `vocabulary` which it says to be an
Roger Ineichen wrote:
Can anybody tell me why we restrict our test setup
in zope eggs and only use a subset of package for
our test setup?
I don't know what you're asking, so I can't tell you why it is wink.
Why do we not use a Zope3 meta egg which contains all
our zope packages as a test
On Thursday 27 September 2007 08:43, Benji York wrote:
Roger Ineichen wrote:
Can anybody tell me why we restrict our test setup
in zope eggs and only use a subset of package for
our test setup?
I don't know what you're asking, so I can't tell you why it is wink.
Why do we not use a
On Thursday 27 September 2007 08:36, Christian Theune wrote:
As deprecation has fallen out of favor, we wonder how to get rid of
vocabularies. We definitely do not want to fork zope.schema. Would a
sufficiently newer version (3.5, 4?) rectify breaking something in this
way?
I estimate that
Hi Benji
Betreff: Re: [Zope3-dev] Why do we restrict our egg testing?
Roger Ineichen wrote:
Can anybody tell me why we restrict our test setup in zope eggs and
only use a subset of package for our test setup?
I don't know what you're asking, so I can't tell you why it is wink.
I
Hi
Betreff: Re: [Zope3-dev] Why do we restrict our egg testing?
[...]
So what do people think about a pretty comprehensive Zope 3
meta egg for testing purposes?
+1
Tests are written for using and not ignoring them.
Otherwise it means we deploy eggs wich are not tested against
all zope.*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
I think that replacing 'index_url' with a gated community of packages
is the only path to sanity here: the contract of the Cheeseshop (share
new releases of all packages with everyone ASAP) is incompatible with
our goals
Roger Ineichen wrote:
Hi Benji
Betreff: Re: [Zope3-dev] Why do we restrict our egg testing?
Roger Ineichen wrote:
Can anybody tell me why we restrict our test setup in zope eggs and
only use a subset of package for our test setup?
I don't know what you're asking, so I can't tell you why it
On 9/27/07, Benji York [EMAIL PROTECTED] wrote:
Second, why would you include all of the zope.* eggs if that particular
package doesn't depend on them?
I suspect there are hidden differences in expectations here. ;-)
Roger, when you assemble an application, are you expecting to find all
of
On Sep 26, 2007, at 7:57 PM, Roger Ineichen wrote:
Hi
Can anybody tell me why we restrict our test setup
in zope eggs and only use a subset of package for
our test setup?
It isn't practical, during development, to test all of the eggs that
might be affected by a change, which is, BTW a
Hi Benji
Betreff: Re: AW: [Zope3-dev] Why do we restrict our egg testing?
[...]
Second, why would you include all of the zope.* eggs if that
particular package doesn't depend on them?
That's the point which I don't understand that nobody is
seeing:
Not my egg depends on other packages.
Marius Gedminas wrote:
On Wed, Sep 26, 2007 at 09:09:37PM -0400, Tres Seaver wrote:
Why does the caller care? She just wants an object which will provide
the 'IFoo' contract on behalf of the passed context. If 'x' is capable
of providing 'IFoo' without help, then failing (or worse, returning
Betreff: Re: AW: [Zope3-dev] Why do we restrict our egg testing?
On 9/27/07, Benji York [EMAIL PROTECTED] wrote:
Second, why would you include all of the zope.* eggs if that
particular package doesn't depend on them?
I suspect there are hidden differences in expectations here. ;-)
On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote:
...
If we are going to have a change log, which we should, I would prefer
it to be included in source distributions.
I want them present in the *installed* egg, not just in the source
distribution: setuptools doesn't preserve source
On Thu, Sep 27, 2007 at 10:09:23AM -0400, Jim Fulton wrote:
On Sep 26, 2007, at 8:22 PM, Tres Seaver wrote:
...
I think that replacing 'index_url' with a gated community of packages
is the only path to sanity here: the contract of the Cheeseshop (share
new releases of all packages with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Tres Seaver wrote:
[snip]
I think that replacing 'index_url' with a gated community of packages
is the only path to sanity here: the contract of the Cheeseshop (share
new releases of all packages with everyone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter wrote:
On Thursday 27 September 2007 08:43, Benji York wrote:
Roger Ineichen wrote:
Can anybody tell me why we restrict our test setup
in zope eggs and only use a subset of package for
our test setup?
I don't know what you're
On 9/27/07, Roger Ineichen [EMAIL PROTECTED] wrote:
No I excpect some of them, but others excpect others.
So I'm pretty shure if we count all different setup then
we can excpect all packages in the summary.
If you think that testing the whole Zope 3 pile with the changed egg
is something that
Hi Tres
Betreff: [Zope3-dev] Re: Why do we restrict our egg testing?
[...]
I thought Roger was one of the folks looking to *reduce* the set of
dependencies his application had on zope3 coee -- testing against the
meta-egg actually makes that problem worse.
Yes, I was one of the folks
On Sep 27, 2007, at 10:00 AM, Stephan Richter wrote:
On Thursday 27 September 2007 09:35, Jim Fulton wrote:
On Sep 26, 2007, at 7:57 PM, Roger Ineichen wrote:
Hi
Can anybody tell me why we restrict our test setup
in zope eggs and only use a subset of package for
our test setup?
It isn't
On Thursday 27 September 2007 11:06, Jim Fulton wrote:
What I really want is a buildout for a big Zope 3 application,
similar to what we've released in the past. Then, I will often
choose to test a change in something as core as cope.component as a
develop egg in that buildout. I would
I've posted this same message on grok-devel mailing list.
I'm just looking for comments from the other side :-)
Thanks a lot in advance.
Hi,
I'm going to start a new project in a few weeks and I'm evaluating possible
frameworks to use.
My best candidate
On Thu, Sep 27, 2007 at 10:33:09AM -0400, Tres Seaver wrote:
Why would we want to pull in all of Zope3 as a dependency (worse, a
hidden one) before testing an egg? If the egg's dependencies are
broken, I *want* the tests to fail. I don't think testing against a
fat meta-egg satisfies that
Hey,
On 9/27/07, Jim Fulton [EMAIL PROTECTED] wrote:
On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote:
[snip]
Including a file other
that README in the root requires extra effort that I don't want to
require -- writing setup.py files is hard enough as it is.
Put the real README.txt and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
On 9/27/07, Jim Fulton [EMAIL PROTECTED] wrote:
On Sep 26, 2007, at 8:26 PM, Tres Seaver wrote:
[snip]
Including a file other
that README in the root requires extra effort that I don't want to
require -- writing
Hey,
On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
Why don't you think it can be solved by having packages themselves
state preferred versions? The cheeseshop can be a festering pool of
madness, as long as the packages I pull from it have reasonable
preferred versions, I should
Hi there. Best to post this on Zope3-users list for a response.
Regards,
David
Matias Surdi wrote:
I've posted this same message on grok-devel mailing list.
I'm just looking for comments from the other side :-)
Thanks a lot in advance.
Hi,
I'm going
Hey,
On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
I don't like it either. I thought we resolved this though so I'm not
sure why we're discussing this. CHANGES.txt in the root dir it is,
right?
- -1. I argued for putting the CHANGES.txt and the real README.txt in
the *package*
Gary Poster wrote at 2007-9-26 15:47 -0400:
...
So, yes, you are right, I stated an extreme position and I could be
argued away from the edge. But the extremity of my position is a
simple, followable rule that I certainly prefer over the case you
describe.
Okay, we disagree.
Non working
Raphael Ritz wrote:
[snip]
I don't see this in conflict. Rather as complementing each other.
Yes, me too. We need human guidelines in any case.
Then we implement tools to help check the human procedure. If the tool
makes some of the human guidelines unnecessary as the tool catches the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
On 9/27/07, Tres Seaver [EMAIL PROTECTED] wrote:
[snip]
I don't like it either. I thought we resolved this though so I'm not
sure why we're discussing this. CHANGES.txt in the root dir it is,
right?
- -1. I argued
Hi,
I thought Christian Theune already did some work on buildbots for Zope 3
buildouts.
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Martijn Faassen wrote at 2007-9-26 22:13 +0200:
...
I am the one who wants to have
the final say in what versions of packages. I want to use.
A linux
distributor needs to have one working set of packages, instead.
He may have one set of packages -- but he knows that not all
of them work
Jim Fulton wrote at 2007-9-26 18:14 -0400:
...
We've just released 1.1. We guess the next release is 1.2. We change
things and release, 1.2dev-r#. Someone fixes a bug and releases
1.1.1. Now there's a dev release of 1.2 that is actually older than
the 1.1.1 release but that
On Sep 27, 2007, at 1:42 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2007-9-26 18:14 -0400:
...
We've just released 1.1. We guess the next release is 1.2. We change
things and release, 1.2dev-r#. Someone fixes a bug and releases
1.1.1. Now there's a dev release of 1.2 that is
Stephan Richter wrote at 2007-9-27 08:55 -0400:
...
Roger is suggesting that we should have one, so that problems are detected
early. Any comments on that?
+1
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
On Wed, Sep 26, 2007 at 08:22:48PM -0400, Tres Seaver wrote:
Anybody running against the Cheeseshop today is *more* on the bleeding
edge than a sysadmin whose production boxes are running 'sid': Debian
has cultural constraits, even for that distro, which are vastly more
restricted than the
Hey,
We have a situation where we have developers, not maintainers, uploading
new versions of packages. There will be no integrated testing done for
all software built on all packages in the cheeseshop. Again, I can see
similarities, but I don't believe linux distributions have *exactly* our
Hey,
On 9/27/07, Brian Sutherland [EMAIL PROTECTED] wrote:
[snip]
There is one I thought of, but it's a bit backwards.
Essentially, Debian has a repository of mostly unmodified original egg
tarballs. And, they've already done the hard work of maintaining sane
dependencies.
So, why not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Anybody running against the Cheeseshop today is *more* on the bleeding
edge than a sysadmin whose production boxes are running 'sid': Debian
has cultural constraits, even for that distro, which are vastly more
restricted than
58 matches
Mail list logo
