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 do
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
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 - forsters
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 d
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. k
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 tho
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 f
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 = zope.schema.Da
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.app
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 mo
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 f
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 A
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 surrou
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
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
bro
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
- zop
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. :-) Som
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 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 problem is that Roger has installed TAR and GZIP. They are also available
in the path. However, for some reason it uses WinZ
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 to
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 3.4.0a
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 pr
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
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 frequ
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 frequ
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 it
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 impleme
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
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 lik
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 info
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?
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-soft
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 info
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):
This registers an adapter providing ILayoutTemplate.
The BrowserPagelet's render method retrieves t
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 not
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
overhe
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 R
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 fut
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 branch
On Wednesday 26 September 2007 10:19, Philipp von Weitershausen wrote:
> > I, for one, promise to read it every time I make a release until I've
> > memorized it.
>
> It would be good if everybody could use it (as least the section on how
> to make releases) as a step-by-step procedure every time.
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 more complex setup.py. I'd
> rather recommend inc
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]
> http://svn.zope.org/*ch
-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 an
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
http://svn.zope.org/*checkout*/Sandbox/philikon/
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
-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
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 more
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
pra
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
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:
IFoo(multi=(obj
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 Ri
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 p
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 ag
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
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 (especial
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
-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
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 easi
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.
Regards
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 keywo
On Wednesday 26 September 2007 11:23, Christian Zagrodnick wrote:
> Ok. Would this break anything when 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 & Chemistry
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 inp
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, other
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
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
> over
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.
"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
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.
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
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 i
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 workin
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
Zope3-d
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
Christian Zagrodnick wrote at 2007-9-26 17:14 +0200:
> ...
>> Terms are very important for me -- and I could not understand
>> "RequestType". What should it mean that "zope.publisher" provides
>> an "IRequestType". What types are these? Do you mean types
>> in the sense of "browser requests", "xml-
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
> getAd
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:
getM
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
>brow
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 0
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
>>> instanti
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, t
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 i
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 cast
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 svn
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 lo
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 nee
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
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 releas
1 - 100 of 126 matches
Mail list logo