We have another case of faulty released eggs.
I reviewed the first that popped up for me, which was
zope.app.publication:
- someone uploaded a stable 3.4.1 egg, but this is just a snapshot
from the trunk, there is no tag for this release.
- the egg does not contain data files correctly.
Hey,
here is an update.
The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.
I can reproduce the problem by creating the packages myself as ZIP files
(doesn't work) and then as tar files (does work).
My proposal for what to
Am Mittwoch, den 26.09.2007, 08:49 + schrieb Christian Theune:
Hey,
here is an update.
The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.
I can reproduce the problem by creating the packages myself as ZIP files
Christian Theune wrote:
Am Mittwoch, den 26.09.2007, 08:49 + schrieb Christian Theune:
Hey,
here is an update.
The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.
I can reproduce the problem by creating the packages
Am Mittwoch, den 26.09.2007, 14:39 +0530 schrieb Baiju M:
We decided not to bump minor release in trunk recently while making
these final release, is it ?
I tried looking for that but didn't find that decision, so I thought
we're doing maintenance branches.
--
gocept gmbh co. kg -
WinZip has the habit of ignoring files it deems empty and paths it
deems too long. Best to avoid.
Stefan
On 26. Sep 2007, at 10:49, Christian Theune wrote:
The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.
--
It
Am Mittwoch, den 26.09.2007, 11:53 +0200 schrieb Stefan H. Holek:
WinZip has the habit of ignoring files it deems empty and paths it
deems too long. Best to avoid.
Nothing about winzip. The files are in there. I also couldn't find an
issue in the egg info files.
--
gocept gmbh co. kg -
On Sep 26, 2007, at 4:16 AM, Christian Theune wrote:
This is IMHO a good example why we shouldn't go for 'everyone can
make a
release'.
I had the same feeling yesterday. I kept silent because the
alternative is that only a few -- including me -- make a release. :)
This deserves more
Christian Theune wrote:
Am Mittwoch, den 26.09.2007, 11:53 +0200 schrieb Stefan H. Holek:
WinZip has the habit of ignoring files it deems empty and paths it
deems too long. Best to avoid.
Nothing about winzip. The files are in there. I also couldn't find an
issue in the egg info
Baiju M wrote:
Christian Theune wrote:
Am Mittwoch, den 26.09.2007, 11:53 +0200 schrieb Stefan H. Holek:
WinZip has the habit of ignoring files it deems empty and paths
it deems too long. Best to avoid.
Nothing about winzip. The files are in there. I also couldn't find an
issue in
Hi,
on our sprint in Bad Sulza we looked at the handling of interface
invariants in z3c.form. There we found a problem in the validation.
Look at the following example.
class IMeetingTime(zope.interface.Interface):
start = zope.schema.Datetime(title=u'start time')
end =
On Wednesday 26 September 2007 04:16, Christian Theune wrote:
The whole list of things that might be relevant here is:
- zope.securitypolicy
- zope.session, zope.app.session
- zope.app.authentication
- zope.app.i18n
- zope.i18nmessageid
- zope.app.applicationcontrol
- zope.app.appsetup
People make mistakes. Can we reduce the number/severity of those
mistakes by creating a Python script to automate the release process as
much as possible? Things like:
- check that the version number in setup.py doesn't match an existing
release in cheeseshop
- check whether you have
On Wednesday 26 September 2007 04:49, Christian Theune wrote:
The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.
I can reproduce the problem by creating the packages myself as ZIP files
(doesn't work) and then as tar files
Previously Stephan Richter wrote:
I totally disagree. If we trust people with repository access, then we have
to
trust them with release making. If you subscribe to the egg process, you have
to do frequent releases.
Why would eggs require more frequent releases?
Wichert.
--
Wichert
Hey,
Jim Fulton wrote:
In any case, you should probably raise this issue on the distutil-sig list.
/me goes to get popcorn.
I hope you have your popcorn ready:
http://mail.python.org/pipermail/distutils-sig/2007-September/008291.html
and here is a blog entry going into the reasoning
Am Mittwoch, den 26.09.2007, 09:16 -0400 schrieb Stephan Richter:
On Wednesday 26 September 2007 04:49, Christian Theune wrote:
The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.
I can reproduce the problem by creating
Stephan Richter wrote:
On Wednesday 26 September 2007 04:49, Christian Theune wrote:
The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.
I can reproduce the problem by creating the packages myself as ZIP files
(doesn't work)
On Sep 26, 2007, at 4:49 AM, Christian Theune wrote:
- Remove the broken files.
I'm not sure if this is related, but I noticed yesterday at least of
couple of eggs that we are using had been removed, in this case from
zope.org. Please, whoever is doing this, stop. If a release is
Stephan Richter wrote:
On Wednesday 26 September 2007 04:16, Christian Theune wrote:
The whole list of things that might be relevant here is:
- zope.securitypolicy
- zope.session, zope.app.session
- zope.app.authentication
- zope.app.i18n
- zope.i18nmessageid
- zope.app.applicationcontrol
-
On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
evening. The stable release was made from that without making a
maintenance branch and bumping the trunk to 3.5.
There is conflicting information here. :-) Some
I'm not too keen on trying to automate this with a Python script. I
suggest we start with a human script. I think Philipp has a start at
this. Philipp, could you remind
us where this is? I suggest we review it and then post it
prominately somewhere that people (I) can easily find it. I,
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 at 3.4.0a1
yesterday
evening. The stable release was made from that without making a
maintenance branch and bumping the trunk
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 at
This would be a good issue to bring up on the distutils-sig list.
Jim
On Sep 26, 2007, at 9:53 AM, Stephan Richter wrote:
On Wednesday 26 September 2007 05:53, Stefan H. Holek wrote:
WinZip has the habit of ignoring files it deems empty and paths it
deems too long. Best to avoid.
The
On Wednesday 26 September 2007 09:20, Wichert Akkerman wrote:
Previously Stephan Richter wrote:
I totally disagree. If we trust people with repository access, then we
have to trust them with release making. If you subscribe to the egg
process, you have to do frequent releases.
Why would
Stephan Richter wrote:
On Wednesday 26 September 2007 09:20, Wichert Akkerman wrote:
Previously Stephan Richter wrote:
I totally disagree. If we trust people with repository access, then we
have to trust them with release making. If you subscribe to the egg
process, you have to do
On Wednesday 26 September 2007 09:36, Martijn Faassen wrote:
I think tagging things in svn is a minimal requirement, though. I
understood that some of this stuff wasn't tagged?
I agree. And Roger simply forgot. As Marius pointed out, as we do more
releases, problems like this will occur
Marius Gedminas wrote:
People make mistakes. Can we reduce the number/severity of those
mistakes by creating a Python script to automate the release process as
much as possible?
[snip]
I'd be happy to work on such a script during the sprint, if someone
could help me figure out what exactly
The current syntax for multi-adaptation makes the interface look like
an object of the adaptation, rather than the actor in the operation.
Instead, multi-adaption should look like this:
IFoo(multi=(obj1, obj2))
or:
IFoo(multi=(obj1, obj2), name='site_foo')
The first draft of such an
On 9/26/07, Gary Poster [EMAIL PROTECTED] wrote:
I should make our own private copies of the eggs we use, to
completely isolate us from these sorts of things, but I have not
gotten around to it...nor am I thrilled at the prospect of that
overhead.
This is also a technical issue: As long as
Stephan Richter wrote:
On Wednesday 26 September 2007 09:36, Martijn Faassen wrote:
I think tagging things in svn is a minimal requirement, though. I
understood that some of this stuff wasn't tagged?
I agree. And Roger simply forgot. As Marius pointed out, as we do more
releases, problems
Stephan Richter wrote:
On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
evening. The stable release was made from that without making a
maintenance branch and bumping the trunk to 3.5.
There is conflicting
Jim Fulton wrote:
I'm not too keen on trying to automate this with a Python script. I
suggest we start with a human script.
I agree.
I think Philipp has a start at this. Philipp, could you remind
us where this is?
Stephan Richter wrote:
On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
evening. The stable release was made from that without making a
maintenance branch and bumping the trunk to 3.5.
There is conflicting
Hi,
there is a recursion problem with Pagelets and layout templates when
you don't register a template for the pagelet.
A layout template could be registered as follows (from z3c.formdemo):
z3c:layout
for=*
layer=z3c.formdemo.layer.IDemoBrowserLayer
template=template.pt
On Wednesday 26 September 2007 10:10, Martijn Faassen wrote:
This way checking CHANGES.txt should tell you what's going on with
releases. If someone forgot to do the last step, you see immediately
something is wrong, as you want to add your change to the 'unreleased'
section but there's
On Sep 26, 2007, at 10:10 AM, Fred Drake wrote:
On 9/26/07, Gary Poster [EMAIL PROTECTED] wrote:
I should make our own private copies of the eggs we use, to
completely isolate us from these sorts of things, but I have not
gotten around to it...nor am I thrilled at the prospect of that
Well said.
Jim
On Sep 26, 2007, at 10:10 AM, Philipp von Weitershausen wrote:
Stephan Richter wrote:
On Wednesday 26 September 2007 09:36, Martijn Faassen wrote:
I think tagging things in svn is a minimal requirement, though. I
understood that some of this stuff wasn't tagged?
I agree. And
Martijn Faassen wrote:
And where is an agreed-upon document that you have to list the next
version in the setup.py file after the release? Because I disagree
with that, since you cannot know the next version.
I disagree with too, for the same reason.
I'm not saying you should foresee the
On Sep 26, 2007, at 10:10 AM, Martijn Faassen wrote:
Stephan Richter wrote:
On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were at 3.4.0a1
yesterday
evening. The stable release was made from that without making a
maintenance
Hey,
On 9/26/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Martijn Faassen wrote:
[snip]
What about using CHANGES.txt, which we should be maintaining anyway?
[snip]
These are very good points. My guide [1] already recommends this practice.
[1]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter wrote:
On Wednesday 26 September 2007 05:02, Christian Theune wrote:
Hmm. While doing that I also noticed that we were at 3.4.0a1 yesterday
evening. The stable release was made from that without making a
maintenance branch and
On Wed, Sep 26, 2007 at 04:19:35PM +0200, Philipp von Weitershausen wrote:
Any other suggestions are highly welcome.
That problem with building eggs on Windows: if you need to pass some
argument to setup.py sdist to get a tar.gz egg, please update
On Wed, Sep 26, 2007 at 09:54:59AM -0400, Jim Fulton wrote:
Sorry, I decided not to reply and hit the wrong button in my mailer. :)
You were just applying explicit is better than implicit to email
replies. :-)
Marius Gedminas
--
Just to be extra clear about this: yes, it is morally wrong for
On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
Hey,
On 9/26/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Martijn Faassen wrote:
[snip]
What about using CHANGES.txt, which we should be maintaining anyway?
[snip]
These are very good points. My guide [1] already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Richter wrote:
On Wednesday 26 September 2007 04:49, Christian Theune wrote:
The issue is that the eggs were released as ZIP files and for some
reason those don't work correctly with the data files.
I can reproduce the problem by creating
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 a
On 26 Sep 2007, at 16:49 , Martijn Faassen wrote:
On 9/26/07, Philipp von Weitershausen [EMAIL PROTECTED]
wrote:
Martijn Faassen wrote:
[snip]
What about using CHANGES.txt, which we should be maintaining anyway?
[snip]
These are very good points. My guide [1] already recommends this
On Wednesday 26 September 2007 10:53, Jim Fulton wrote:
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
On Sep 26, 2007, at 10:04 AM, Brandon Craig Rhodes wrote:
The current syntax for multi-adaptation makes the interface look like
an object of the adaptation, rather than the actor in the operation.
Instead, multi-adaption should look like this:
IFoo(multi=(obj1, obj2))
or:
On Wednesday 26 September 2007 10:53, Tres Seaver wrote:
Why would we zip / tar files up by hand, rather than using 'setup.py
sdist'?
We use this, but on Windows it uses winzip by default. You have to specify
the --format option as Philipp pointed out earlier.
Regards,
Stephan
--
Stephan
On Wednesday 26 September 2007 10:19, Christian Zagrodnick wrote:
there is a recursion problem with Pagelets and layout templates when
you don't register a template for the pagelet.
Yep, nasty, isn't it?
The problem is, that ILayoutTemplate is derived from IPageTemplate.
This is why the
On Wednesday 26 September 2007 10:10, Philipp von Weitershausen wrote:
Stephan Richter wrote:
On Wednesday 26 September 2007 09:36, Martijn Faassen wrote:
I think tagging things in svn is a minimal requirement, though. I
understood that some of this stuff wasn't tagged?
I agree. And
On 2007-09-15 17:35:20 +0200, Roger Ineichen [EMAIL PROTECTED] said:
Hi Christian
Betreff: [Zope3-dev] Re: skin support for xmlrpc
On 2007-09-14 18:54:01 +0200, Fred Drake [EMAIL PROTECTED] said:
On 9/14/07, Roger Ineichen [EMAIL PROTECTED] wrote:
If you register views for a base request
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 keyword arguments to get around limitations (especially
backward
On 2007-09-18 19:51:43 +0200, Dieter Maurer [EMAIL PROTECTED] said:
Christian Zagrodnick wrote at 2007-9-18 08:35 +0200:
On 2007-09-16 09:03:47 +0200, Dieter Maurer [EMAIL PROTECTED] said:
Ok, then I suggest:
* Provide an IRequestType interface in zope.publisher
Does this name sound wrong?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
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
Jim Fulton wrote:
I'm not too keen on trying to automate this with a Python script. I
suggest we start with a human script. I think Philipp has a start at
this. Philipp, could you remind
us where this is? I suggest we review it and then post it prominately
somewhere that people (I) can
On 2007-09-26 17:01:45 +0200, Stephan Richter
[EMAIL PROTECTED] said:
On Wednesday 26 September 2007 10:19, Christian Zagrodnick wrote:
there is a recursion problem with Pagelets and layout templates when
you don't register a template for the pagelet.
Yep, nasty, isn't it?
The problem is,
Stephan Richter wrote:
[snip]
Doing another checkout of the tag
will create a significant overhead to the release process of a package.
I'd like to highlight this. We need to be careful we don't increase
release overhead too much, otherwise it won't happen/people will make
mistakes.
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
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.
Thanks for fixing this!!
Regards,
Stephan
--
Stephan Richter
CBU Physics
Hey,
Zagy asked about this a while ago:
http://mail.zope.org/pipermail/zope3-dev/2007-August/thread.html
Our feeling is that better default error messages would be welcome and
the breakage that this might cause would be acceptable.
I'd be happy to implement this tomorrow, a bit more explicit
On Sep 26, 2007, at 11:19 AM, Martijn Faassen wrote:
Stephan Richter wrote:
[snip]
Doing another checkout of the tag will create a significant
overhead to the release process of a package.
I'd like to highlight this. We need to be careful we don't increase
release overhead too much,
On Wed, Sep 26, 2007 at 11:16:46AM -0400, Tres Seaver wrote:
Jim Fulton wrote:
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.
On Wednesday 26 September 2007 11:33, Christian Theune wrote:
Zagy asked about this a while ago:
http://mail.zope.org/pipermail/zope3-dev/2007-August/thread.html
Our feeling is that better default error messages would be welcome and
the breakage that this might cause would be acceptable.
On Wed, Sep 26, 2007 at 05:19:45PM +0200, Martijn Faassen wrote:
Stephan Richter wrote:
[snip]
Doing another checkout of the tag will create a significant overhead to
the release process of a package.
I'd like to highlight this. We need to be careful we don't increase release
overhead too
On 9/26/07, Marius Gedminas [EMAIL PROTECTED] wrote:
Reducing overhead is why I proposed an automated tool.
Exactly. I like this approach myself.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
Hey,
My opinions:
It'd be nice if getMultiAdapter's functionality was in reach without
typing: import zope.component; zope.component.getMultiAdapter. The
IFoo() single adapter lookup shows us a way to make this possible: a
method (in this case __call__ on the interface). It does bother me on
Hey,
Marius Gedminas wrote:
[snip]
+1 for CHANGES.txt (or NEWS.txt) in a separate file from README.txt
+1 for the latest changelog entries visible on the cheeseshop page (see
an announcement, go to cheeseshop, see whether you want to upgrade or
not)
+1 for README.txt and CHANGES.txt available
On Wed, 2007-09-26 at 17:18 +0200, Martijn Faassen wrote:
I definitely think we should work out a human procedure *first*.
But some tools to assist the human in doing repetitive, failure-prone
work (releasing versions of many eggs) would definitely be appreciated
by me.
Perhaps these
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, then? Hm, it does appear to
be there by default. I checked grok 0.10's tgz and it's there, and we
didn't do anything special.
Do
Hey,
On 9/26/07, Fred Drake [EMAIL PROTECTED] 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, then? Hm, it does appear to
be there by default. I checked grok 0.10's tgz
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, then? Hm, it does
appear to
be there by default. I checked grok 0.10's tgz and
Martijn Faassen wrote at 2007-9-25 19:57 +0200:
...
If you choose for flexibility first, people will need to think about
versions all the time.
I follow Tres argumentation: somehow the Linux distributors
have this problem mostly solved:
Standard distributions come with a set of known working
Philipp von Weitershausen wrote at 2007-9-25 18:49 +0200:
...
I think we should just not raise any deprecation warnings at all.
Just the imports for BBB and be done with it.
I like this very much :-)
--
Dieter
___
Zope3-dev mailing list
Philipp von Weitershausen wrote at 2007-9-26 16:19 +0200:
...
* That you should never ever delete a release, even if it's a
brown bag release.
But, if you know it is severely broken and you do not have
a working replacement, you should remove it as soon as possible
-- to avoid more people to
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, in:
getMultiAdapter([x], IFoo)
or
getAdapter(x,
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, in:
Stephan Richter wrote at 2007-9-26 09:12 -0400:
...
I totally disagree. If we trust people with repository access, then we have to
trust them with release making. If you subscribe to the egg process, you have
to do frequent releases.
Maybe, if you fix dependancies to single versions ;-)
--
Gary Poster wrote at 2007-9-26 09:39 -0400:
...
- Remove the broken files.
I'm not sure if this is related, but I noticed yesterday at least of
couple of eggs that we are using had been removed, in this case from
zope.org. Please, whoever is doing this, stop. If a release is
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, then? Hm, it does appear to
be there by default. I checked grok
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 is retuned. Nothing is
instantiated. OTOH, in:
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:33 PM, Dieter Maurer wrote:
Gary Poster wrote at 2007-9-26 09:39 -0400:
...
- Remove the broken files.
I'm not sure if this is related, but I noticed yesterday at least of
couple of eggs that we are using had been removed, in this case from
zope.org. Please, whoever
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 is
To add a novice's perspective:
When I first learned Zope, I tried the syntax:
adapter = IFoo(context1, context2)
It took me hours and the help of Philipp to determine why context2 was being
returned. I saw the symmetry between IFoo(context) and a cast in other
languages and figured I'd just
Jim Fulton wrote:
On Sep 26, 2007, at 3:32 PM, Philipp von Weitershausen wrote:
[snip]
* working from an svn checkout, in which case setuptools will use the
list of which files are in svn and which aren't as a hint of what to
include and what not
Certainly, I expect CHANGES.txt to be in
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2007-9-26 16:19 +0200:
...
* That you should never ever delete a release, even if it's a
brown bag release.
But, if you know it is severely broken and you do not have
a working replacement, you should remove it as soon as possible
--
Fred Drake wrote:
On 9/26/07, Marius Gedminas [EMAIL PROTECTED] wrote:
Reducing overhead is why I proposed an automated tool.
Exactly. I like this approach myself.
Sure, I support it too. That said, I'd still like the process *without*
the tool comprehensible by normal human beings. The
Dieter Maurer wrote:
Martijn Faassen wrote at 2007-9-25 19:57 +0200:
...
If you choose for flexibility first, people will need to think about
versions all the time.
I follow Tres argumentation: somehow the Linux distributors
have this problem mostly solved:
While I don't dispute we should
Philipp von Weitershausen wrote:
Stephan Richter wrote:
Because I disagree with that, since you cannot know the next version.
You can always know the minimum version. If you just released 3.4.2, I
think it's sensible to point the next release to 3.4.3. If you later
decide that you really
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 always know the minimum version. If you just released
3.4.2, I think it's sensible to point the next release
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 the release from the tag.
Changing tags is not that good.
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 the
On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:
That said, I'd still like the process *without*
the tool comprehensible by normal human beings.
Agreed; I was trying to usurp the goal of having a reasonable process.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score
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 always know the minimum version. If you just released
3.4.2, I
On Wednesday 26 September 2007 17:34, Jim Fulton wrote:
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
On 26 Sep 2007, at 22:34 , Benji York wrote:
Philipp von Weitershausen wrote:
Stephan Richter wrote:
Because I disagree with that, since you cannot know the next
version.
You can always know the minimum version. If you just released
3.4.2, I think it's sensible to point the next release
1 - 100 of 121 matches
Mail list logo
