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
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
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
, 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
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
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 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
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 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
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
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
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
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
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
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
701 - 768 of 768 matches
Mail list logo