new threads on zope-dev.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
a
stubborn desire not to require setuptools for ZODB. Anyway, if
someone wants to ehlp with the setup script, it would be appreciated,
Otherwise, I'll get to it eventually. In the mean time, I suggest
not running the ZODB tests.
Jim
--
Jim Fulton
Zope Corporation
is accurate. FWIW, I have a fairly open mind on this
topic. Lots of good points are being made. :)
Jim
On Oct 7, 2007, at 5:13 PM, Martijn Faassen wrote:
Jim Fulton wrote:
On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote:
[snip]
- We need a *realistic* (especially wrt available resources
On Oct 6, 2007, at 6:07 PM, Martijn Faassen wrote:
Jim Fulton wrote:
On Oct 6, 2007, at 5:24 AM, Martijn Faassen wrote:
[snip]
What I really don't like about this proposal is that it talks
about updating index pages. If I understand this right, an
updated index page will force everybody
releases. I'll note that the problem is
exacerbated by the incompatibilities that (to some degree inevitably)
often occur in Python releases. Big-bang releases don't prevent
update problems.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev
On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote:
On 10/6/07, Jim Fulton [EMAIL PROTECTED] wrote:
- We need to decide what a Zope 3 release is (or maybe multiple
flavors). I favor copying the linux experiences, but have an open
mind.
I'm not sure what you mean with that,
I mean we
On Oct 7, 2007, at 7:33 AM, Lennart Regebro wrote:
On 10/6/07, Jim Fulton [EMAIL PROTECTED] wrote:
Only people who ask for updates.
Which by default is every time somebody runs a buildout, right?
Yes
I think this depends on the use cases. I think most people would
like to get bug fixes
the
release process for the larger Zope 3 ecosystem.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
On Oct 6, 2007, at 5:06 AM, Martijn Faassen wrote:
Jim Fulton wrote:
On Oct 5, 2007, at 1:59 PM, Martijn Faassen wrote:
[snip]
but moved to a new place. zope.app.error, is, I understand, gone
now.
I have no idea about this specific move. If there was a
zope.app.error before
, then it seems to me that
versions in a meta egg or a buildout configuration should work well.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail
resources. We also
shouldn't plan significant tasks that people won't care enough to
work on. I think the classic Zope 3.4 release is a good example of a
large effort that really wouldn't benefit many people, if any.
Jim
--
Jim Fulton
Zope Corporation
semantics would be useful, but there isn't a way to do it in
setuptools. We can achieve the same effect on the server. For
example, with this software, you could chain several KGSs together.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing
minor
tweaking) to combine KGSs on the server.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
projects have version #s that are independent from the
Zope version #s. Any similarity is a hysterical accident. :)
Jim
P.S. This has nothing to do with whether the Zope 3.4 release is
important.
--
Jim Fulton
Zope Corporation
___
Zope3-dev
On Oct 5, 2007, at 1:59 PM, Martijn Faassen wrote:
Jim Fulton wrote:
On Oct 5, 2007, at 12:07 PM, Martijn Faassen wrote:
Hi there,
zope.error is a 3.5 egg, but is needed by 3.4.x releases. I guess
this also happened because large package refactorings happened
and were released as 3.4.x
out the buildout
- maybe change the index option to point to a particular KGS
- check out the project(s) they want to test and configure them as
develop eggs
- run the buildout test script.
Hopefully, this will give us much greater stability than we've had up
to now.
--
Jim Fulton
Zope
.
Are you suggesting that other people aren't thinking about this and
don't care?
I hope that the proposal for setting up a known-good-set index will
be helpful. I'm sure Stephan would like to know the versions you
chose. I imagine he'll be able to get those by looking at Grok.
Jim
--
Jim
On Oct 4, 2007, at 9:25 AM, Baiju M wrote:
Jim Fulton wrote:
On Oct 4, 2007, at 6:51 AM, Philipp von Weitershausen wrote:
On 4 Oct 2007, at 00:59 , Jim Fulton wrote:
On Oct 3, 2007, at 3:44 PM, Philipp von Weitershausen wrote:
Jim Fulton wrote:
I'd really like to get to closure
Any objections?
This would basically involve retiring the zope3-dev list and moving
zope3 developers to the zope-dev list.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman
to avoid typos. Especially in subject lines. :/
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
On Oct 4, 2007, at 10:02 AM, Baiju M wrote:
Jim Fulton wrote:
Any objections?
This would basically involve retiring the zope3-dev list and moving
zope3 developers to the zope-dev list.
+1
What about retiring #zope3-dev IRC channel and only using #zope ?
I though
until they are needed. Of course, tags should always be created.
There are other improvements that might be made, but let's not let
the perfect be the enemy of the good.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev
On Oct 3, 2007, at 11:12 AM, Benji York wrote:
Jim Fulton wrote:
I'd really like to get to closure on the current approved release
process.
+1
There are other improvements that might be made, but let's not
let the perfect be the enemy of the good.
This isn't perfect, so I get
On Oct 3, 2007, at 11:46 AM, Benji York wrote:
Jim Fulton wrote:
For example, a packaging of MochiKit 1.3.1 might have a version #
like 1.3.1-1, or, if it is exciting enough: 1.3.1-1.1
I assume setuptools interprets version numbers like this in a
reasonable way.
AFAIK. :)
Jim
On Oct 2, 2007, at 6:52 PM, Stephan Richter wrote:
On Tuesday 02 October 2007 17:14, Jim Fulton wrote:
One hole I see is giving people guidance on what needs to be tested
(and how) before a release is made. My preference would be to rely
heavily on judgement with a few checks so
On Oct 3, 2007, at 3:44 PM, Philipp von Weitershausen wrote:
Jim Fulton wrote:
I'd really like to get to closure on the current approved release
process. Philipp, would you mind separating the release process
into a separate file? Or do you mind if I do it?
Done: http://svn.zope.org
On Oct 2, 2007, at 3:29 AM, Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
Maybe grok was already trimmed down. In my case, I basically
eliminated all ZMI support (since I didn't need it). I got about
40%,
Grok is trimmed down in the sense that it doesn't depend on all
Zope 3
warrant a 3.5 release!
Agreed. Someone needs to sloow down. Speed kills. deserves to
be added to the Zen of Python. (Actually, ZoP does have a variation
of that.)
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
be that hard to finish
at this point.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
distributors. In the mean
time, changing packages that lots of other people depend on requires
judgement and care. If you don't think you're up to it, then don't
try it.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev
is a non-final release.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
On Sep 26, 2007, at 10:35 AM, Jim Fulton wrote:
This is also a technical issue: As long as zc.buildout and
setuptools
foolishly accept dependency links from an egg, it'll be painful to
detect accidental reliance on external repositories.
That's a good point. I wouldn't go so far as to say
*not* kidding about that: taking shortcuts durng the release
process transfers pain / cost to everyone downstream.
Amen, brother. Well said.
+1
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http
rather than the develop eggs so that
tests could be run against the distros. This would probably be
something good to do when I have some time to get back to buildout.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
verifyclassifiers.py
Cool.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
On Sep 26, 2007, at 6:14 PM, Jim Fulton wrote:
...
I agree that the develop egg case is problematic. I'd like to
think about that.
Well, I thought and I thought
I could probably arrange that develop eggs created by buildout got
their versions from the buildout spec. Something like
On Oct 1, 2007, at 11:17 AM, Jim Fulton wrote:
On Oct 1, 2007, at 11:09 AM, Lennart Regebro wrote:
On 9/29/07, Jim Fulton [EMAIL PROTECTED] wrote:
This helps in cases where you want the configuration for a package,
but you don't want some of the configuration that it includes
On Sep 28, 2007, at 11:14 AM, Martijn Faassen wrote:
...
On 9/28/07, Jim Fulton [EMAIL PROTECTED] wrote:
[snip]
we could investigate whether we can't come up with something that:
* doesn't break the existing notation. The cleanest way to support
such non-interference seems to be to do
. This would open the door, sometime in the
future, to allowing multi-adaptation via: IFoo(ob1, ob2).
So, any volunteers to try to implement this?
I insist on reviewing any change before checking it in. This will
create an unavoidable bottle neck.
Jim
--
Jim Fulton
Zope Corporation
, but potentially a lot of work.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
which is a peer of 'setup.py' should be a stub which points to
the real versions.
I can live with this, but I don't like it. It feels more complicated
to me.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub
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 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
thought though.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
/zope3-dev/jim%40zope.com
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
%40zope.com
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Sorry, I decided not to reply and hit the wrong button in my mailer. :)
On Sep 26, 2007, at 9:54 AM, Jim Fulton wrote:
On Sep 26, 2007, at 9:51 AM, Stephan Richter wrote:
On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were
)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
--
Jim Fulton
Zope Corporation
that this is a policy that should be overrideable.
Checkins to buildout (with tests, of course) accepted.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
-- Professional Zope documentation and
training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing
is so complex It will take me a largish chunk of time to
unwind this.
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote:
On Wednesday 26 September 2007 10:40, Jim Fulton wrote:
What about using CHANGES.txt, which we should be maintaining anyway?
I agree with a change log. CHANGES.txt is difficult to get included
in distributions. Having one requires
benefit from having an interface method for doing
multi and named adaptation, I don't think the benefit is worth the cost.
I'm -1 on your proposal and -0 on my variation. :)
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev
On Sep 26, 2007, at 11:08 AM, Brandon Craig Rhodes wrote:
Jim Fulton [EMAIL PROTECTED] writes:
On Sep 26, 2007, at 10:04 AM, Brandon Craig Rhodes wrote:
Instead, multi-adaption should look like this:
IFoo(multi=(obj1, obj2))
IFoo(multi=(obj1, obj2), name='site_foo')
Ah, using
, otherwise it won't happen/people will
make mistakes.
+10
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
want to
require -- writing setup.py files is hard enough as it is.
I'm not crazy about Tres' idea of putting these files in the Python
packages themselves, but it does have the advantage that it causes
the files to be included in eggs as well as source distributions.
Jim
--
Jim Fulton
Zope
On Sep 26, 2007, at 3:00 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2007-9-26 11:29 -0400:
...
IFoo(x)
IBar(multi=(x,y))
Actually, that is not the case. If x already provides IFoo, then in
the first case, the existing object is retuned. Nothing is
instantiated. OTOH
On Sep 26, 2007, at 3:32 PM, Philipp von Weitershausen wrote:
Jim Fulton wrote:
On Sep 26, 2007, at 1:18 PM, Fred Drake wrote:
On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
What does one need to tell setup.py to make sure CHANGES.txt is
available? I understand it isn't by default
On Sep 26, 2007, at 3:37 PM, Dieter Maurer wrote:
Jim Fulton wrote at 2007-9-26 15:10 -0400:
...
Jim Fulton wrote at 2007-9-26 11:29 -0400:
...
IFoo(x)
IBar(multi=(x,y))
Actually, that is not the case. If x already provides IFoo,
then in
the first case, the existing object
that the first release
branch for that tag was made, so as not to accidentally get a version
#.)
I'd prefer not to make an edict, so Benji and Gary will now persuade
you that this is the best way to go. ;)
Jim
--
Jim Fulton
Zope Corporation
On Sep 26, 2007, at 5:28 PM, Stephan Richter wrote:
On Wednesday 26 September 2007 17:18, Jim Fulton wrote:
- Update changes.txt, adding a heading for the new # and date
- Create a tag
- check out or switch to the tag
- Set the version in setup.py on the tag. Check it in.
- Make
On Sep 26, 2007, at 5:37 PM, Philipp von Weitershausen wrote:
On 26 Sep 2007, at 23:18 , Jim Fulton wrote:
On Sep 26, 2007, at 4:34 PM, Benji York wrote:
Philipp von Weitershausen wrote:
Stephan Richter wrote:
Because I disagree with that, since you cannot know the next
version.
You can
on ellipsis that didn't consume newlines.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
On Sep 26, 2007, at 6:23 PM, Philipp von Weitershausen wrote:
On 27 Sep 2007, at 00:14 , Jim Fulton wrote:
Let's say X depends on Y and I'm developing them simultaneously
as development eggs in one sandbox (e.g. buildout). I add a
feature to Y that I'd like to use in X. That means I'll
something that will work w/o
buildout. Oh well.
JIm
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
On Sep 25, 2007, at 11:22 AM, Martijn Faassen wrote:
Hey,
On 9/25/07, Jim Fulton [EMAIL PROTECTED] wrote:
[snip]
I'm skeptical that you are going to get these changes in setuptools.
I'm not crazy about them myself as they make writing setup files even
more complicated. I'd much rather have
ever *do* need to make a backward-incompatible change to
a package, we'll have some license to clean up rotten apis.
Jim
--
Jim Fulton
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev
probably tell
them to switch to zc.testbrowser.
--
http://worldcookery.com -- Professional Zope documentation and
training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
--
Jim
and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361
12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540
as they present themselves.
I'm not going to reply to any replies to this post as I don't intend
to spend any more time on this issue myself.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
On Sep 6, 2007, at 4:02 AM, Chris Withers wrote:
Martin Aspeli wrote:
Jim Fulton wrote:
I'm very much against making setuptools *more* complicated
than it already is.
Indeed, but surely managing known good sets of components
comes under its remit of version management?
Sure. It does
On Sep 5, 2007, at 10:48 AM, Chris Withers wrote:
Jim Fulton wrote:
I'm very much against making setuptools *more* complicated than it
already is.
Indeed, but surely managing known good sets of components comes
under its remit of version management?
Sure. It does this via requirements
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
*more* complicated than it
already is.
Perhaps buildout (and setuptools) should grow a mechanism for being
able to override/resolve version conflicts.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
for new tests, but *only* if they are well
documented. I've never seen a classic unit test that was, but I'm
open to the theoretical possibility. :)
BTW, I've seen poorly documented doctests too.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO
other way to block it. In any case, it had nothing
to do with blocking setuptools.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp
, as a general
principal, errors should be displayed through adaptation -- basically
views.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation
setuptools. Not any other clients.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
On Aug 23, 2007, at 1:53 AM, Christian Zagrodnick wrote:
On 2007-08-22 16:12:42 +0200, Jim Fulton [EMAIL PROTECTED] said:
On Aug 22, 2007, at 8:16 AM, Christian Zagrodnick wrote:
Hi,
I'm doing things wich z3c.zalchemy and trying to find out why my
database connections are kept open even
files and thus I prefer to include
the change log in README.txt.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com
; gc.collect()
before your last getrefcount call.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http
be a problem, at
least for buildout users. People using easy_install can configure it
to use the simple index. They might want to lobby to have
easy_install use the simple index by default.
If there are no strong objections, I plan to stop unhiding old releases.
Jim
--
Jim Fulton
and finable by
setuptools. The simple index achieves that.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http
incompatibility.
I eventually came to the conclusion that our original conclusion was
sound, but that we should only introduce backward incompatibilities
when the need is very dire, as it will cause lots of pain.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
On Aug 22, 2007, at 4:15 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
A while ago, we had a discussion about backward compatibility and
decided that only major releases should be backward compatible. So,
for example, a 1.2 release should be backward
at the top, I don't think that size is an issue.
Note that with the latest version of buildout, buildout uses the new
simple index, http://cheeseshop.python.org/simple by default, so
there is no longer a buildout performance penalty for having large
cheeseshop pages.
Jim
--
Jim Fulton
(or at least enable) people to do better method verification
and possibly provide other kinds of verification.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope
framework used for zmi_views doesn't work with
menu items registered for classes. Someone should fix that too. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
:
[buildout]
prefer-final = false
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
On Aug 20, 2007, at 2:02 PM, Martin Aspeli wrote:
Jim Fulton wrote:
I'm about to make a new release of zc.buildout that uses a
different policy for selecting distributions. In particular, by
default, zc.buildout will now prefer final distributions over non-
final ones
On Aug 20, 2007, at 2:18 PM, Jim Fulton wrote:
On Aug 20, 2007, at 2:02 PM, Martin Aspeli wrote:
Jim Fulton wrote:
I'm about to make a new release of zc.buildout that uses a
different policy for selecting distributions. In particular, by
default, zc.buildout will now prefer final
On Aug 20, 2007, at 1:18 PM, Jim Fulton wrote:
I'm about to make a new release of zc.buildout that uses a
different policy for selecting distributions. In particular, by
default, zc.buildout will now prefer final distributions over non-
final ones. If there are final and non-final
. In particular, I'll need to see the import
order.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http
that in this particular case, the real problem was circular
imports. Circular imports create bugs that are hard or impossible to
test for. I'd love to outlaw them. I wish we at least had a tool to
warn about circular imports when testing.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
I've just released a b5 egg which should correct the problem.
Jim
On Aug 15, 2007, at 9:51 AM, Wichert Akkerman wrote:
Previously Jim Fulton wrote:
On Aug 14, 2007, at 7:32 PM, Paul Carduner wrote:
Hello zope3-dev,
I came across an error I have not seen before. Just for reference,
here
-b2) works correctly.
Just ran into this one. I think removing it is the right decision.
b2 did work for me, but b4 just broke on me.
Try b5.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
hard thing to test for sadly. We need to fix this.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http
1 - 100 of 768 matches
Mail list logo
