[Zope3-dev] faulty releases and pypi access
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. unpacking the egg misses the zcml files. - the 3.4.0 egg is invalid as well as the zcml files are missing too I did: - create a tag for the brown-bagged 3.4.1 release - removed the uploaded files from the cheeseshop as I don't have newer replacements immediately available. 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 I'll go through those now and try to fix it up. This is IMHO a good example why we shouldn't go for 'everyone can make a release'. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 (Roger, maybe you can do that?): - Remove the broken files. - Create tags for the wrong trunk releases - Create a new release and tag in tar format. I'll show what I mean by releasing a fix for zope.app.i18n. Am Mittwoch, den 26.09.2007, 08:16 + schrieb Christian Theune: We have another case of faulty released eggs. - zope.securitypolicy Actually this is zope.app.securitypolicy. - zope.session, zope.app.session - zope.app.authentication - zope.app.i18n - zope.i18nmessageid - zope.app.applicationcontrol - zope.app.appsetup -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 (doesn't work) and then as tar files (does work). My proposal for what to do (Roger, maybe you can do that?): - Remove the broken files. - Create tags for the wrong trunk releases - Create a new release and tag in tar format. I'll show what I mean by releasing a fix for zope.app.i18n. 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. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 myself as ZIP files (doesn't work) and then as tar files (does work). My proposal for what to do (Roger, maybe you can do that?): - Remove the broken files. - Create tags for the wrong trunk releases - Create a new release and tag in tar format. I'll show what I mean by releasing a fix for zope.app.i18n. 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. We decided not to bump minor release in trunk recently while making these final release, is it ? (But I have already bumped some of them earlier, but we can change it unless a 3.5 release has come out) Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 - forsterstrasse 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 doesn't necessarily do it in chronological order, though. --Douglas Adams ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 - forsterstrasse 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access
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 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
Re: [Zope3-dev] faulty releases and pypi access [update]
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 files. When I manually download and extract zope.app.appsetup zip file I can see a 'schema' folder and a ZCML file under that. But when I easy_install, that 'schema' directory is missing. Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 the egg info files. When I manually download and extract zope.app.appsetup zip file I can see a 'schema' folder and a ZCML file under that. But when I easy_install, that 'schema' directory is missing. Oops, that is not a ZCML file but a schema.xml file -- Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] z3c.form: handling of interface invariants
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.Datetime(title=u'end time')
@zope.interface.invariant
def start_before_end(obj):
if obj.start obj.end:
raise zope.interface.Invalid('start time must be before
end time')
If only the end field is displayed in a form and the end date is set
to value smaller than start, the invariant does not prevent saving
the form, so it is possible to save invalid data.
This happens because accessing obj.start leads to an exception
z3c.form.validator.NoInputData which is swallowed in
z3c.form.validator.InvariantsValidator.validateObject().
Possible solutions:
- The invariant expects to get an object for checking but it gets a
z3c.form.validator.Data object which only contains the data the user
entered. So this Data object could look up the missing value on the
real object which is accessible on the __context__ attribute on the
Data object.
- Change the order things are done:
1. set a save-point (non-optimistic)
2. write the values the user entered on the object
3. validate invariants
4. If an invariant raises an exception, roll back to the save-point.
This solution requests that the back-end supports non-optimistic
save-points. But we can get rid of the Data class.
We'll start an implementation of the second approach on a branch of
z3c.form now to show if it works.
Any thoughts?
--
Yours sincerely,
Michael Howitz
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon: +49 345 12298898 · fax: +49 345 12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access
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 I'll go through those now and try to fix it up. I'll review those with Roger and fix what needs to be fixed. This is IMHO a good example why we shouldn't go for 'everyone can make a release'. 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. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Automated egg releases
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 modified but not committed (or unversioned) files in the source tree - check that you've created a tag in subversion for this release (or, alternatively, offer to create the tag for you) - build an egg, install it locally in a temporary directory, then run the test suite to check for any missing files or whatever (a somewhat related idea would be to set up a buildbot to check for new zope-related egg releases and run their test suite in a sandbox, to notice breakages and email the guilty parties) - run the correct setup.py command to build/register/upload the egg to cheeseshop and/or www.zope.org I'd be happy to work on such a script during the sprint, if someone could help me figure out what exactly it should to do. Marius Gedminas -- If something has not yet gone wrong then it would ultimately have been beneficial for it to go wrong. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 (does work). Okay, thanks a lot for this research. So this is a problem that noone could anticipate. Roger tried the eggs on his machine and they worked there. So that's something we learned: We have to make tag.gz releases. BTW, which OS so you use? Roger told me he did several releases with Windows at Lovely Systems and all was fine there. But then everyone else at Lovely has Macs. My proposal for what to do (Roger, maybe you can do that?): - Remove the broken files. - Create tags for the wrong trunk releases - Create a new release and tag in tar format. I'll show what I mean by releasing a fix for zope.app.i18n. I will review all the released eggs with Roger. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access
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 Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
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 surrounding Zope 3 and Grok: http://faassen.n--tree.net/blog/view/weblog/2007/09/26/0 Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 the packages myself as ZIP files (doesn't work) and then as tar files (does work). Okay, thanks a lot for this research. So this is a problem that noone could anticipate. Roger tried the eggs on his machine and they worked there. Right -- and those subtle things are hard to find if not anticipated. So that's something we learned: We have to make tag.gz releases. Right. However this seems like a bug in setuptools. (Sidenote: isn't .tar.gz the default of setuptools on windows too?) BTW, which OS so you use? Roger told me he did several releases with Windows at Lovely Systems and all was fine there. But then everyone else at Lovely has Macs. I'm on Linux. We at gocept have a mixture between Linux and Mac OS X systems. I will review all the released eggs with Roger. K, thanks. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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) and then as tar files (does work). Okay, thanks a lot for this research. So this is a problem that noone could anticipate. Roger tried the eggs on his machine and they worked there. Yes, this is really a weird setuptools bug. Apparently it can't properly install package metadata from ZIP distributions on Linux and Mac. So that's something we learned: We have to make tag.gz releases. Yes. You can do this via python setup.py sdist --format=gztar -- 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/archive%40mail-archive.com
PLEASE don't remove eggs [was Re: [Zope3-dev] faulty releases and pypi access [update]]
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 brown-bagged as far as you are concerned for some reason, please do not assume it is ok to delete for others. 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. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access
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 - zope.app.appsetup I'll go through those now and try to fix it up. I'll review those with Roger and fix what needs to be fixed. This is IMHO a good example why we shouldn't go for 'everyone can make a release'. 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. I think tagging things in svn is a minimal requirement, though. I understood that some of this stuff wasn't tagged? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 people say we need branches, others say we don't. 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. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Automated egg releases
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, for one, promise to read it every time I make a release until I've memorized it. Jim On Sep 26, 2007, at 9:13 AM, 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? Things like: - check that the version number in setup.py doesn't match an existing release in cheeseshop - check whether you have modified but not committed (or unversioned) files in the source tree - check that you've created a tag in subversion for this release (or, alternatively, offer to create the tag for you) - build an egg, install it locally in a temporary directory, then run the test suite to check for any missing files or whatever (a somewhat related idea would be to set up a buildbot to check for new zope-related egg releases and run their test suite in a sandbox, to notice breakages and email the guilty parties) - run the correct setup.py command to build/register/upload the egg to cheeseshop and/or www.zope.org I'd be happy to work on such a script during the sprint, if someone could help me figure out what exactly it should to do. Marius Gedminas -- If something has not yet gone wrong then it would ultimately have been beneficial for it to go wrong. ___ 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 list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 3.5. There is conflicting information here. :-) Some people say we need branches, others say we don't. 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. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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.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 people say we need branches, others say we don't. 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. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) 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 ___ 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 list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
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 problem is that Roger has installed TAR and GZIP. They are also available in the path. However, for some reason it uses WinZip. Now, he has tested the eggs on his machine and they worked. Oh man, ... Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access
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 eggs require more frequent releases? Have you tried working with a pure egg-based project? It's unavoidable. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access
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 frequent releases. Why would eggs require more frequent releases? Have you tried working with a pure egg-based project? It's unavoidable. I have worked on large projects where you had modules and you could only use released versions. I don't see the problem. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access
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 frequently. Making mistakes is human, so let's develop a tool that does some basic checking. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Automated egg releases
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 should to do. +10! Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] reasonable syntax for multi-adaptation
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 implementation could simply intercept a multi keyword passed to InterfaceBasePy.__call__(), and hand control over to the traditional getMultiAdapter. The old getMultiAdapter call should always remain available, but code will become much easier to read as the new syntax is adopted and single- and multi-adaptation become visually congruent. I'll be happy to develop a patch and test cases. -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: PLEASE don't remove eggs [was Re: [Zope3-dev] faulty releases and pypi access [update]]
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 zc.buildout and setuptools foolishly accept dependency links from an egg, it'll be painful to detect accidental reliance on external repositories. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access
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 like this will occur frequently. Making mistakes is human, so let's develop a tool that does some basic checking. I'm not yet convinced that we will have more releases. We have more releases now because we're trying to get to stable versions. After that, the eggs are on their own and I think we'll make much less releases. But even if we got more releases to do, I don't see the problem. With more releases we'd get more practice and make less mistakes. One of the things we should realize in this process is that -- even though setuptools makes it so damn easy to register and uplaod stuff to PyPI -- releases are actually important business. They can't just be created in a jiffy. They require attention and concentration. And a well-defined process. -- 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/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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 information here. :-) Some people say we need branches, others say we don't. I think it'd be good to have a tag in any case. A tag can always be converted into a branch later. 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. What about using CHANGES.txt, which we should be maintaining anyway? Before making a release, change CHANGES.txt, and convert the section: unreleased -- Fixed bugs blah blah. To: 3.5.1 (2007-09-26) -- Fixed bugs blah blah. That is, come up with a release number, a release date, update setup.py with the release number, and tag it. Then, after the release, add in a new section: unreleased -- 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 nothing there yet. You can then reconstruct what happened from the cheeseshop or the tags, and put in a new 'unreleased' section. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Automated egg releases
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-software.txt I suggest we review it and then post it prominately somewhere that people (I) can easily find it. Yes, that would be good. I 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. I certainly do this now and as far as I remember, back in the one-big-tarball days, we all did using the MakingARelease wiki page. By the way, I'm planning on spelling out several more things: * That you should never ever delete a release, even if it's a brown bag release. * That setup.py sdist should be run from a **clean** checkout of the tag that you just created. That avoids - forgetting to tag or tagging the wrong thing (happened to me and others) - forgetting to clean up the 'build' directory (happened to me and my egg contained old stuff that shouldn't have been in there) - forgetting to check in files; setuptools will only include package data files that are in subversion (happened to me and other people) * That you should check if the long_description renders as proper reStructuredText before you update the PyPI page (reST errors will cause the rendering to be all messed up. Any other suggestions are highly welcome. -- 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/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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 information here. :-) Some people say we need branches, others say we don't. And where is an agreed-upon document that you have to list the next version in the setup.py file after the release? It's not agreed upon, it's just what I wrote down: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt Back when I put it up for discussion, all I got was a huge discussion about PEP8, which is just a small and rather unimportant paragraph. Unfortunately it's somewhere towards the beginning of the file. I wonder if anybody read any further and got to the actually important stuff. Sigh. 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 need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). -- 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/archive%40mail-archive.com
[Zope3-dev] Pagelet and LayoutTemplate recursion
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 / This registers an adapter providing ILayoutTemplate. The BrowserPagelet's render method retrieves the template for the pagelet's contents (i.e. not the outer wrap) as follows: template = zope.component.getMultiAdapter( (self, self.request), IPageTemplate) The problem is, that ILayoutTemplate is derived from IPageTemplate. This is why the pagelet tries to render its contents with the layout template. I'm not sure what to do about this. a) Explicitly check that the template is *not* an ILayoutTemplate in BrowserPagelet.render b) make z3c:template use another interface which is also derived from IPageTemplate and use the new interface in BrowserPagelet.render. c) ... ? Comments, remarks? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 nothing there yet. You can then reconstruct what happened from the cheeseshop or the tags, and put in a new 'unreleased' section. Good point; of course I agree. :-) A well-maintained CHANGES.txt file is worth a lot. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: PLEASE don't remove eggs [was Re: [Zope3-dev] faulty releases and pypi access [update]]
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 overhead. 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 foolishly, but I would say 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
Re: [Zope3-dev] Re: faulty releases and pypi access
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 Roger simply forgot. As Marius pointed out, as we do more releases, problems like this will occur frequently. Making mistakes is human, so let's develop a tool that does some basic checking. I'm not yet convinced that we will have more releases. We have more releases now because we're trying to get to stable versions. After that, the eggs are on their own and I think we'll make much less releases. But even if we got more releases to do, I don't see the problem. With more releases we'd get more practice and make less mistakes. One of the things we should realize in this process is that -- even though setuptools makes it so damn easy to register and uplaod stuff to PyPI -- releases are actually important business. They can't just be created in a jiffy. They require attention and concentration. And a well-defined process. -- 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 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] Re: faulty releases and pypi access [update]
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 future, but I think you can very well know the next *anticipated* version. Doing so has some benefits: * We need *a* convention, otherwise people will either release an egg with the same version twice (this happened to Jim with the ZODB yesterday, due to the lack of a convention) or skip a release number because they both increment after and before a release (happened to Roger yesterday; it's harmless but confusing). * It is a convention that setuptools encourages (third para in http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-releases-using-subversion) * On the trunk, you'll know what release line it is for. Is it 3.4.x? Or 3.5.x? * Even more important, when the trunk was used for 3.4.x and now you want to add a feature and want to bump it to 3.5.x, you explicitly see this in setup.py. And then you know that you have to create a 3.4 branch before you do this. 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/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt -- 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/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 and bumping the trunk to 3.5. There is conflicting information here. :-) Some people say we need branches, others say we don't. I think it'd be good to have a tag in any case. A tag can always be converted into a branch later. Yup. I don't think there is disagreement about tags and we don't really need agreement on branches. 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. 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 including a change log in README.txt. Before making a release, change CHANGES.txt, and convert the section: unreleased -- Fixed bugs blah blah. To: 3.5.1 (2007-09-26) -- Fixed bugs blah blah. That is, come up with a release number, a release date, update setup.py with the release number, and tag it. Then, after the release, add in a new section: unreleased -- 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 nothing there yet. You can then reconstruct what happened from the cheeseshop or the tags, and put in a new 'unreleased' section. I agree except for the location of the change log. Jim P.S. ZODB's NEWS.txt/History.txt aren't workable for me and I plan to switch ZODB to using a change log in it's readme. Unfortunately, it's setup 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
[Zope3-dev] Re: faulty releases and pypi access [update]
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/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt I can't find my description of this practice in the guide. In particular, the practice of using unreleased entries. Note that if you already anticipate the version number, you can instead do this: 1.3.7 (unreleased) --- And then change the unreleased to the date once you're releasing. The method I describe above tries to make sure that some amount of reconstruction can be done in case of mistakes. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-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 bumping the trunk to 3.5. There is conflicting information here. :-) Some people say we need branches, others say we don't. 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. +1, The trunk should *always* say 'unreleased' or 'trunk', except in the five minutes before cutting a release tag (if not using a release branch). Release branches should have '-branch' or something appended to the version, except just before cutting a release tag. Anything else makes it too easy to cut a premature / broken release; such mistakes are going to damange our story if we don't get out ahead of them. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+nGq+gerLs4ltQ4RAtrkAJoDIeCeHW3BVdlWYLklwf6MrOV2MwCgy43W enYWkDaVC0IHZV4Fb0K7KDA= =WGvo -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Automated egg releases
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/foundation/maintaining-software.txt because it currently says just | * Upload the package to PyPI with the following command:: | | python setup.py register sdist upload Marius Gedminas -- Added mysterious, undocumented --scanflags and --fuzzy options. -- nmap 3.0 announcement signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [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 us to have written RetchMail, and it is morally wrong for you to use it. But try it, it's really fast! -- http://open.nit.ca/wiki/index.php?page=RetchMail signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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 recommends this practice. [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt I can't find my description of this practice in the guide. In particular, the practice of using unreleased entries. Now I did. It was in a section that didn't mention CHANGES.txt (other areas do), so I didn't find it. So forget about my complaint, I'm sorry. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-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 the packages myself as ZIP files (doesn't work) and then as tar files (does work). Okay, thanks a lot for this research. So this is a problem that noone could anticipate. Roger tried the eggs on his machine and they worked there. So that's something we learned: We have to make tag.gz releases. Why would we zip / tar files up by hand, rather than using 'setup.py sdist'? BTW, which OS so you use? Roger told me he did several releases with Windows at Lovely Systems and all was fine there. But then everyone else at Lovely has Macs. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+nKD+gerLs4ltQ4RAl66AKCtLSJDOAVavsYVpw9A5EgIq1zg+QCgy5jc cjUVQfmRlkGYFqZtuCy8fUg= =/bGl -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 complex setup.py. I'd rather recommend including a change log in README.txt. -1. I don't like that. We include CHANGES.txt via the long description; that's good enough for me. Do you think that the change log should be included in the distribution? 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] Re: faulty releases and pypi access [update]
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 practice. [1] http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/ maintaining-software.txt I can't find my description of this practice in the guide. In particular, the practice of using unreleased entries. It's way down at the bottom, under the Releasing software section. Note that if you already anticipate the version number, you can instead do this: 1.3.7 (unreleased) --- And then change the unreleased to the date once you're releasing. That's exactly what the guide recommends. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt. -1. I don't like that. We include CHANGES.txt via the long description; that's good enough for me. Do you think that the change log should be included in the distribution? I am indifferent about it. I cannot see a strong argument for having it in the release. Because people read the changes before deciding to download the package. On the other hand, package managers for Linux distributions will hate us, probably. ;-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] reasonable syntax for multi-adaptation
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=(obj1, obj2), name='site_foo') Ah, using keyword arguments to get around limitations (especially backward compatibility issues) with the current API is a neat idea. If we were going to do this though, I think a method syntax would be cleaner. As in: IFoo.adapt([ob1, ob2], 'site_foo', None) Note that IFoo(ob) has some special semantics that don't apply to the multi- or named-adapter case. In particular: - The object is returned if it already provides the interface, and - The object's __conform__ method is used if it is present. Neither of these make sense in the multi- or named-adapter cases. Given the differences in semantics, I wouldn't want to mix the APIs. An added complication is that interfaces don't provide adaption directly, but via a hook. The existing hook api wouldn't work for mult or named adaptation, so a new hook would be needed. While I can see 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@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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 Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Pagelet and LayoutTemplate recursion
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 pagelet tries to render its contents with the layout template. I'm not sure what to do about this. Roger and I discussed this issue over the weekend and just have not had the time to work it out. a) Explicitly check that the template is *not* an ILayoutTemplate in BrowserPagelet.render Good solution. :-) b) make z3c:template use another interface which is also derived from IPageTemplate and use the new interface in BrowserPagelet.render. Also a good solution. :-) I think both approaches are fine. Roger and I had decided on (b) when we discussed it. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access
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 Roger simply forgot. As Marius pointed out, as we do more releases, problems like this will occur frequently. Making mistakes is human, so let's develop a tool that does some basic checking. I'm not yet convinced that we will have more releases. We have more releases now because we're trying to get to stable versions. After that, the eggs are on their own and I think we'll make much less releases. I would not hold my breath on this one, but I have unsupported hope you are right. ;-) But even if we got more releases to do, I don't see the problem. With more releases we'd get more practice and make less mistakes. This is logically incorrect. It is the same as saying: More guns make us safer. The error rate would have to drop by the same factor the releases are increased, which I do not think will be the case, especially since more people are doing releasing now., One of the things we should realize in this process is that -- even though setuptools makes it so damn easy to register and uplaod stuff to PyPI -- releases are actually important business. They can't just be created in a jiffy. They require attention and concentration. And a well-defined process. I agree. But all the process in the world will not drop the error rate to zero. I think that Marius' tool suggestion is very good and I also think we should seriously look at how Linux distributions manage that process. Having some staging mechanism would be good. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: skin support for xmlrpc
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 type, you probably will open a backdor in other projects. Because I'm not advocating registering views for the base request types generally, but only the way to specify in the URL what the request type is. Because sometimes we really do want completely separate sets of XML-RPC (or whatever) interfaces. Ok, then I suggest: * Provide an IRequestType interface in zope.publisher * Provide an ++api++ traverser in zope.traversing which does `getUtility(IRequestType, *name*)`. * define class IBrowserSkinType(IRequestType) * Leave ++skin++ for IBrowserSkinType or just make it the same as ++api++ * Keep layer= on xmlrpc:view, browser:page etc. Comments? If I understand the concept correct. This is a builtin backdoor. Doesn't this allow to bypass the Apache rewrite rule? With: http://www.foobar.com/++api++xmlrpc/doSomething If the rewrite rule in Apache is: RewriteRule (/?.*) http://localhost:8080/++skin++OnlyHere/++vh++https:www.foobar.com:443/++$1 [P,L] Or does the ++api++ namespace recognize the skin? Which means the url rewritten url is. With: http://www.foobar.com/++skin++OnlyHere/++api++xmlrpc/doSomething A way to avoid this is to allow applying a skin / request type only once. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: reasonable syntax for multi-adaptation
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 compatibility issues) with the current API is a neat idea. If we were going to do this though, I think a method syntax would be cleaner. As in: IFoo.adapt([ob1, ob2], 'site_foo', None) -1. Unfortunately the singular verb adapt makes it look like normal adaptation is what is being called for - it looks here like you are trying to adapt a list to the IFoo interface. Maybe .multiadapt()? Note that IFoo(ob) has some special semantics that don't apply to the multi- or named-adapter case. Agreed! The semantics are different. But mightn't we simply document this difference between single- and multi-adaptation everywhere we need to, rather than letting it force us into splitting the adapter syntax into two unwieldy pieces? I would not imagine that I would be confused encountering documenting that said: Call IFoo(x) to adapt a single object x to the IFoo interface, and IBar(multi=(x,y)) to have the adapter registry find and invoke a multi-adapter that adapts the pair of objects x and y to the IBar interface. When performing single adaptation, the object x itself is simply returned if it already offers the IFoo interface; and if the object offers a __conform__ method, then this is called with the IFoo interface as its argument in place of the normal adaptation machinery. So, I am not sure that I see yet the problem with mixing APIs. For me, the essential issue is that in both single- and multi- adaptation you are returned an instance of an adapter that has been instantiated with the objects you are adapting. Both of these syntaxes: IFoo(x) IBar(multi=(x,y)) suggest this fact, even to the novice Python programmer, because they make it look like something is being instantiated with the arguments given, and returned. Doesn't the benefit of such clarity and symmetry outweigh whatever slight awkwardness might exist in the sort of documentation I suggested above? An added complication is that interfaces don't provide adaption directly, but via a hook. The existing hook api wouldn't work for mult or named adaptation, so a new hook would be needed. I had assumed that IBar(multi=(obj1, obj2)) would simply dispatch to the existing getMultiAdapter() call; how, exactly, would hooks get involved and complicate things? Feel free to just cite a line number and tell me to go read, all I need is a pointer to get started understanding this. -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: skin support for xmlrpc
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? It suggests the the interface has to do with request types, maybe browser, xmlrpc, ... It that what we want? IAPIType? IApi? IHTTPApiType? /me is confused again. :/ Me, too. 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-rpc requests, ftp requests, ... or something else? I figured that what I actually mean is IHTTPRequestType, which is a generalisation of IBrowserSkinType for all HTTP requests. Does this make sense? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
-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 difficult to get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt. -1. I don't like that. We include CHANGES.txt via the long description; that's good enough for me. Do you think that the change log should be included in the distribution? +10. The cheeseshop metadata is not where I would expect to look for a changelog; having it readable there is only helpful *before* I've downloaded. FWIW, I think that both README.txt and CHANGES.txt should be package data, so that they are discoverable after installing an egg. The top-level README.txt should be boilerplate, and point to those files (the setup.py process can then stitch them all todgether). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+nfe+gerLs4ltQ4RApwzAJ9WjIb1eWRU1LZA8Tm6hAnVLgcnnwCgovHP HlNNaXNmE8X/4nz4oVVpPmE= =PqY/ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Automated egg releases
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 easily find it. I, for one, promise to read it every time I make a release until I've memorized it. 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 could be made lint-like initially. I.e. you run them and the tool reports possible problems (no tag created, version number in CHANGES.txt appears wrong, setup.py misses information we want in there, etc). Once that's in place, we could introduce features that actually perform actions. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Pagelet and LayoutTemplate recursion
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, that ILayoutTemplate is derived from IPageTemplate. This is why the pagelet tries to render its contents with the layout template. I'm not sure what to do about this. Roger and I discussed this issue over the weekend and just have not had the time to work it out. a) Explicitly check that the template is *not* an ILayoutTemplate in BrowserPagelet.render Good solution. :-) b) make z3c:template use another interface which is also derived from IPageTemplate and use the new interface in BrowserPagelet.render. Also a good solution. :-) I think both approaches are fine. Roger and I had decided on (b) when we discussed it. Ok. Would this break anything when z3c:template suddenly uses a different interface? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Automated egg releases
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, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
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 keyword arguments to get around limitations (especially backward compatibility issues) with the current API is a neat idea. If we were going to do this though, I think a method syntax would be cleaner. As in: IFoo.adapt([ob1, ob2], 'site_foo', None) -1. Unfortunately the singular verb adapt makes it look like normal adaptation is what is being called for - it looks here like you are trying to adapt a list to the IFoo interface. Maybe .multiadapt()? Note that IFoo(ob) has some special semantics that don't apply to the multi- or named-adapter case. Agreed! The semantics are different. But mightn't we simply document this difference between single- and multi-adaptation everywhere we need to, rather than letting it force us into splitting the adapter syntax into two unwieldy pieces? I don't consider either unwieldy. ... So, I am not sure that I see yet the problem with mixing APIs. The semantics of the call would change in fundamental ways based on the arguments passed. I think this is very bad. If you disagree, sorry. :) For me, the essential issue is that in both single- and multi- adaptation you are returned an instance of an adapter that has been instantiated with the objects you are adapting. Both of these syntaxes: 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, IFoo) either there is an error or some factory will be called. x won't be returned unless the factory happens to return it. ... An added complication is that interfaces don't provide adaption directly, but via a hook. The existing hook api wouldn't work for mult or named adaptation, so a new hook would be needed. I had assumed that IBar(multi=(obj1, obj2)) would simply dispatch to the existing getMultiAdapter() call; how, exactly, would hooks get involved and complicate things? Feel free to just cite a line number and tell me to go read, all I need is a pointer to get started understanding this. zope.interface does *not* depend on zope.component. It only does adaptation the way it does because it provides a hook that zope.component fills. Other people are using zope.interface with different adaptation schemes. Adding multi- or named- adaption support would require a similar hook. I don't really have time to continue this discussion. You made a reasonable proposal, but for various reasons I've tried to explain, I don't support it. 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
Re: [Zope3-dev] Re: Pagelet and LayoutTemplate recursion
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 Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Better default validation error messages
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 input whether to do that or not would be welcome. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Automated egg releases
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, 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
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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. CHANGES.txt is difficult to get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt. -1. I don't like that. We include CHANGES.txt via the long description; that's good enough for me. Do you think that the change log should be included in the distribution? +10. The cheeseshop metadata is not where I would expect to look for a changelog; having it readable there is only helpful *before* I've downloaded. FWIW, I think that both README.txt and CHANGES.txt should be package data, so that they are discoverable after installing an egg. The top-level README.txt should be boilerplate, and point to those files (the setup.py process can then stitch them all todgether). Example from Debian: all packages have a /usr/share/doc/$packagename with the changelog and readme in there, and this is a Very Good Thing. +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 to you after you install an egg. Marius Gedminas -- Despite all appearances, your boss is a thinking, feeling, human being. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Better default validation error messages
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. I'd be happy to implement this tomorrow, a bit more explicit input whether to do that or not would be welcome. I am all for this, but would rather fix this in the context of the form framework than in the schema package (where it never belonged). I can chat with you about this on IRC and/or Skype/Wengo, if you like. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Automated egg releases
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 much, otherwise it won't happen/people will make mistakes. Reducing overhead is why I proposed an automated tool. To put it in perspective, I believe the proper sequence of things is 1. keep doing stuff so you learn (from mistakes and whatnot) what needs to be done 2. document the process because (1) you'll forget what you learned, and (2) other people won't know what you learned 3. automate, because following a long process by hand is boring, and bored people make mistakes. Marius Gedminas -- I would suggest re-naming rmbdd(). I _assume_ that dd stands for data dependent, but quite frankly, rmbdd looks like the standard IBM we lost every vowel ever invented kind of assembly lanaguage to me. -- Linus Torvalds signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Automated egg releases
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: reasonable syntax for multi-adaptation
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 occasion that I need to invoke multi adaptation in such an entirely different way. I must also note that it's a very common intuition to want to do something like IFoo((a, b)). Even though my intuition is usually like Jim's and prefer to have two different methods, given different semantics, I consider the differences in semantics here such a grey area I'm on the fence. That the object itself is returned if it already provides the interface in single adaptation is a difference in semantics, but since there's just no possibility of doing so in the case of multi adaptation anyway, you can argue whether this is a difference in semantics or not, just some semantics that doesn't apply. __conform__ is a bigger difference, but given that polymorphism abounds in object oriented code, having different behavior with different inputs is not *that* surprising either. Anyway, if we want to split methods, I'm fine with a properly named method for multi-adaptation on the interface. For completeness' sake you'd also want a properly named method on the interface for single-adaptation. IFoo.adapt() for normal adaptation IFoo.multiadapt() for multi adaptation sound reasonable to me. We then explain that if you call IFoo directly, IFoo.adapt is called. These could then also be extended to support named adapter lookup and such. Since Jim is -0 on his variation, he's not really against it, if someone else does the work, right? :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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 to you after you install an egg. +1 for those too. 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. I don't understand Jim's objections to a separate CHANGES.txt then. Is it just because it's more work to include the changes on the cheeseshop homepage if you separate out the text over multiple files? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Automated egg releases
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 could be made lint-like initially. I.e. you run them and the tool reports possible problems (no tag created, version number in CHANGES.txt appears wrong, setup.py misses information we want in there, etc). Once that's in place, we could introduce features that actually perform actions. +100 An advisory tool could also optionally use Cheesecake. - Michael R. Bernstein signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 you mean available in the unpacked sdist, or as part of the installation? I don't think any of README, README.txt, CHANGES, CHANGES.txt (from the root of the distribution, not from inside the package) are actually installed. If they are, I'd love to know where. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 and it's there, and we didn't do anything special. Do you mean available in the unpacked sdist, or as part of the installation? I don't think any of README, README.txt, CHANGES, CHANGES.txt (from the root of the distribution, not from inside the package) are actually installed. If they are, I'd love to know where. I'm just talking about the sdist. Jim gave me the impression that this was somehow difficult, but perhaps he meant something else. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 it's there, and we didn't do anything special. Do you mean available in the unpacked sdist, or as part of the installation? I don't think any of README, README.txt, CHANGES, CHANGES.txt (from the root of the distribution, not from inside the package) are actually installed. If they are, I'd love to know where. By default READM(.txt) is installed in a source distribution. Anything else in the root (aside from setup.py of course and source files themselves) aren't without extra setup chants. (These chants can be figured out with some effort. I never remember them, so, if I want to do something like this, I have to figure them out again or try to find an example with them.) If we are going to have a change log, which we should, I would prefer it to be included in source distributions. Including a file other that README in the root requires extra effort that I don't want to require -- writing setup.py files is hard enough as it is. 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 Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Known working sets II [was: Eggification redux]
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 components and quite weak dependancy declarations. When I install additional components, I will be told about potential conflicts (based on the weak dependancies) and asked what to do (install nevertheless, upgrade more things to get dependancies right or abort). Usually, I do not have to worry about versions -- only occationally (when I see conflict lists) or even more rarely, when something breaks even though there has not been a conflict. We currently made bad experiences with weak dependancies. I see several reasons for this: * not yet ready distributions (insufficiently tested, alpha quality) have been uploaded to PyPI We are now aware that we must not do things like this * installation tools have prefered newer versions over older ones, even when the newer versions were development/alpha while the older ones have been stable The tools meanwhile have changed and stick preferably to stable versions * The installation tools work incrementally with dependancies rather than based on a global dependancy graph. This is not yet changed. Maybe, our bad experience are drastically reduced when the above reasons are taken care of -- even with weak dependancies? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] AW: Proposal, free views
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-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Automated egg releases
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 get this broken state and allow them to usually get the previous working state instead. Mayby PyPI has a different solution to this then deleting the release? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
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, IFoo) either there is an error or some factory will be called. x won't be returned unless the factory happens to return it. Is this not an irrelevant implementation detail? Should I not concentrate on: I get an object related to x implementing IFoo? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
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: getMultiAdapter([x], IFoo) or getAdapter(x, IFoo) either there is an error or some factory will be called. x won't be returned unless the factory happens to return it. Is this not an irrelevant implementation detail? No, the specified behavior is different. 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
Re: [Zope3-dev] faulty releases and pypi access
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 ;-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: PLEASE don't remove eggs [was Re: [Zope3-dev] faulty releases and pypi access [update]]
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 brown-bagged as far as you are concerned for some reason, please do not assume it is ok to delete for others. I do not agree. When I have understood Christian correctly, then these distributions were not working at all (they lacked ZCML files). Distributions not working at all should be deleted as soon as one recognizes they are not working at all -- to limit the damage they may cause. Of course, not having a tag in the SVN repository is not a sufficient reason to remove otherwise fully working distributions again. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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.10's tgz and it's there, and we didn't do anything special. Do you mean available in the unpacked sdist, or as part of the installation? I don't think any of README, README.txt, CHANGES, CHANGES.txt (from the root of the distribution, not from inside the package) are actually installed. If they are, I'd love to know where. By default READM(.txt) is installed in a source distribution. Anything else in the root (aside from setup.py of course and source files themselves) aren't without extra setup chants. (These chants can be figured out with some effort. I never remember them, so, if I want to do something like this, I have to figure them out again or try to find an example with them.) Actually, no package data is ever included unless you're either * 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 * creating a MANIFEST.in file to tell setuptools what to include explicitly. -- 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/archive%40mail-archive.com
Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
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: getMultiAdapter([x], IFoo) or getAdapter(x, IFoo) either there is an error or some factory will be called. x won't be returned unless the factory happens to return it. Is this not an irrelevant implementation detail? No, the specified behavior is different. Hm. But getAdapter and getMultiAdapter may return x as well (when the factory decides to do this). Thus, why is it relevant? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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, 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 you mean available in the unpacked sdist, or as part of the installation? I don't think any of README, README.txt, CHANGES, CHANGES.txt (from the root of the distribution, not from inside the package) are actually installed. If they are, I'd love to know where. By default READM(.txt) is installed in a source distribution. Anything else in the root (aside from setup.py of course and source files themselves) aren't without extra setup chants. (These chants can be figured out with some effort. I never remember them, so, if I want to do something like this, I have to figure them out again or try to find an example with them.) I was wrong. Dang. I think I understand setuptools/distutils and I'm proven wrong again. Sheesh. Actually, no package data is ever included unless you're either * 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. I've just doeble checked that files from the root of the package that are checked into svn *are* included in sdists. I retract my objection to CHANGES.txt and offer my apologies. 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
Re: PLEASE don't remove eggs [was Re: [Zope3-dev] faulty releases and pypi access [update]]
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 is doing this, stop. If a release is
brown-bagged as far as you are concerned for some reason, please do
not assume it is ok to delete for others.
I do not agree.
When I have understood Christian correctly, then these distributions
were not working at all (they lacked ZCML files).
Distributions not working at all should be deleted as soon
as one recognizes they are not working at all -- to limit
the damage they may cause.
Of course, not having a tag in the SVN repository is
not a sufficient reason to remove otherwise fully working
distributions again.
If you released some software that does an os.system('rm -rf .') or
something, then, OK, maybe you can convince me. So, yes, I have a
line past which maybe deletion is ok with me.
But I disagree with yours--code is still importable without ZCML
files and I may only be using a given package in that way and relying
on it in my buildouts, not having noticed the lack of zcml because it
is irrelevant to me.
In the vast majority of cases--for instance, in the case of someone
who apparently removed a zope.app.wsgi egg recently--it simply
shouldn't be done.
So, yes, you are right, I stated an extreme position and I could be
argued away from the edge. But the extremity of my position is a
simple, followable rule that I certainly prefer over the case you
describe.
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
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 retuned. Nothing is instantiated. OTOH, in: getMultiAdapter([x], IFoo) or getAdapter(x, IFoo) either there is an error or some factory will be called. x won't be returned unless the factory happens to return it. Is this not an irrelevant implementation detail? No, the specified behavior is different. Hm. But getAdapter and getMultiAdapter may return x as well (when the factory decides to do this). Thus, why is it relevant? Because they don't take into account what x already provides. They will always call some factory. Also, they never call __conforms__. 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] Re: reasonable syntax for multi-adaptation
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 multiple contexts to an adapter. This makes intuitive sense to the newbie. Returning the second argument as the default adapter was strange to me, a seeming violation fo the explicit comparisons to a cast (see the Summary on page 196 of Philipp's book, fourth bullet point). As a more experienced Zope developer, I never make this mistake. But I still yearn for a simple syntax that makes multi-adaption as easy as adaption. While IFoo.adapt() and IFoo.multiadapt() are nice, neither is as simple as saying: adapter = IFoo((context1, context2), default) So, there seem to be advantages here for both the newbie and the experienced developer. Martijn notes the advantage for the experienced; I am noting the it just does what I expect simplicity for the newbie. (of course, I'd prefer the cast syntax didn't have a default option at all, so it was really like a cast, but what's done is done). I don't pretend to understand Jim's objections, as I don't have that mastery of the z3 internals. But, I plead for you all to see this from a user's perspective, not from that of the internals. It is expected, for a user, that adapting (context1, context2) would not return context1 as the adapter, even if it already implements the interface, because one is attempting MULTI-adaption. As for what is called internally, as a user of z3, I'm not sure it matters, as long as I get the adapter back that I expect or a default or error otherwise. At the least, I guess, if z3 isn't going to change, the rhetoric of comparing the adaptation syntax to a cast should change, since, to a neewbie, the exceptions are confusing and, in my course of learning, were not clear. Derek On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote: 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 occasion that I need to invoke multi adaptation in such an entirely different way. I must also note that it's a very common intuition to want to do something like IFoo((a, b)). Even though my intuition is usually like Jim's and prefer to have two different methods, given different semantics, I consider the differences in semantics here such a grey area I'm on the fence. That the object itself is returned if it already provides the interface in single adaptation is a difference in semantics, but since there's just no possibility of doing so in the case of multi adaptation anyway, you can argue whether this is a difference in semantics or not, just some semantics that doesn't apply. __conform__ is a bigger difference, but given that polymorphism abounds in object oriented code, having different behavior with different inputs is not *that* surprising either. Anyway, if we want to split methods, I'm fine with a properly named method for multi-adaptation on the interface. For completeness' sake you'd also want a properly named method on the interface for single-adaptation. IFoo.adapt() for normal adaptation IFoo.multiadapt() for multi adaptation sound reasonable to me. We then explain that if you call IFoo directly, IFoo.adapt is called. These could then also be extended to support named adapter lookup and such. Since Jim is -0 on his variation, he's not really against it, if someone else does the work, right? :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/derek.richardson%40gatech.edu ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: faulty releases and pypi access [update]
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. I've just doeble checked that files from the root of the package that are checked into svn *are* included in sdists. I retract my objection to CHANGES.txt and offer my apologies. Excellent, we all agree then. :) I did go and check, which is why I was so mystified by your statements that it wasn't there. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Automated egg releases
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 -- to avoid more people to get this broken state and allow them to usually get the previous working state instead. Mayby PyPI has a different solution to this then deleting the release? The alternative is to upload a new release with a newer version number. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Automated egg releases
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 automation cannot be an reason to create a horrendously complicated release process, just because we can. I may change my mind on this after we've seen a tool work reliably for everybody for all use cases for a couple of years. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Known working sets II [was: Eggification redux]
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 look at package management systems, they don't have *our* problems exactly solved. I have 20 different buildouts installed, which may or may use the same pool of eggs, and may use different versions of the same package. I am the one who wants to have the final say in what versions of packages. I want to use. A linux distributor needs to have one working set of packages, instead. Standard distributions come with a set of known working components and quite weak dependancy declarations. When I install additional components, I will be told about potential conflicts (based on the weak dependancies) and asked what to do (install nevertheless, upgrade more things to get dependancies right or abort). Usually, I do not have to worry about versions -- only occationally (when I see conflict lists) or even more rarely, when something breaks even though there has not been a conflict. A linux distribution, unless you're on debian unstable, has quite a strict control over what packages enter a common pool. They do not release a newer version of a library unless they know the software that depends on it either works or can be upgraded to it. We have a situation where we have developers, not maintainers, uploading new versions of packages. There will be no integrated testing done for all software built on all packages in the cheeseshop. Again, I can see similarities, but I don't believe linux distributions have *exactly* our problems solved. Our buildouts are used as development environments, not only deployment environments. We currently made bad experiences with weak dependancies. I see several reasons for this: * not yet ready distributions (insufficiently tested, alpha quality) have been uploaded to PyPI We are now aware that we must not do things like this Better diligence here would help. It would help me most as a framework developer developing the framework - I can upgrade to newer versions of my dependencies without so much stuff breaking. * installation tools have prefered newer versions over older ones, even when the newer versions were development/alpha while the older ones have been stable The tools meanwhile have changed and stick preferably to stable versions Sticking to stable versions helps, until a new stable version is released. Then all the old stuff suddenly starts using the *new* stable version, and probably break. * The installation tools work incrementally with dependancies rather than based on a global dependancy graph. This is not yet changed. Maybe, our bad experience are drastically reduced when the above reasons are taken care of -- even with weak dependancies? I used to believe that, but after seeing Grok 0.10 break once or twice *every* week for the last month, I don't believe it anymore. We're talking about the same release, breaking over and over again as something goes wrong with some egg somewhere. I want these dependencies pinned down hard. That said, I believe there are ways to solve these problems without hardcoding them in install_requires. I hope we can have the benefits of weak dependencies while having the safetly of hardcoded ones. See here: http://faassen.n--tree.net/blog/view/weblog/2007/09/26/0 Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Why not leave the version totally out of the setup.py in the trunk? After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We could either leave the version on the branch at the last release or continue the trend of mad bumping and have it at the next release (which since this is a branch, we can actually predict). I prefer the last version, but next would work too. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Gary and Benji made me pay attention to this point. :) I *really* don't like setting the version to the number for the next release, since one often doesn't know what it is. Why not leave the version totally out of the setup.py in the trunk? Benji and Gary won me over to this point of view. :) After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We should not require branches. I would only bother creating maintenance branches when they are needed. Z, B, G, and I propose the following: - Leave the version # out of setup.py on the trunk and on branches. When it is time to make a release, either from the trunk or from a maint branch: - 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. (BTW, when creating maint branches after the fact, the branch should be made by copying the trunk at the revision 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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. I'd rather check in a aversion number then. ;-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 release from the tag. Changing tags is not that good. I'd rather check in a aversion number then. ;-) This is exactly what we've been doing for Zope 3 releases -- for the same reason. I think it is the one acceptable and reasonable change to a tag. The benefit of forcing us to release from a tag is, imo, significant. 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
Re: [Zope3-dev] Re: Automated egg releases
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 upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 think it's sensible to point the next release to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Gary and Benji made me pay attention to this point. :) I *really* don't like setting the version to the number for the next release, since one often doesn't know what it is. Maybe. However, when you do the actual release then, you're still going to have to find out which version number to use. On release branches this is a trivial step, of course: You just look at the latest tagged version and increment accordingly. On the trunk it might be trickier. After 1.0, do we have 1.1? Or 2.0? Maye this aspect isn't such a big deal, though. Why not leave the version totally out of the setup.py in the trunk? Benji and Gary won me over to this point of view. :) There's a *really* good reason for putting the upcoming version number in setup.py, though: development eggs. 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 have to change X's version dependency regarding Y so that it now depends on Ya.b where a.b is the latest release that didn't have the feature I added. Will Y with the setup.py stating version='unreleased' satisfy the Ya.b requirement that X (rightfully) has? If not, then I think we have a problem. If yes, then I find that very confusing. I know that if Y's setup.py stated version='a.b-dev', it will work. This what my guide currently suggests (including taking it out just for release tags). After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We should not require branches. I would only bother creating maintenance branches when they are needed. +1 Z, B, G, and I propose the following: Who's Z? :) - Leave the version # out of setup.py on the trunk and on branches. When it is time to make a release, either from the trunk or from a maint branch: - 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. I could live with that, even with the fact that you'd be modifying a tag, as long as it's done in this exact order and the only modificdations to a tag woudl be setting setup.py. I still see the development egg case the best argument for putting the next anticipated version number into setup.py. I think the compromise of version number + 'dev' marker would work best. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 the version in setup.py on the tag. Check it in. - Make the release from the tag. Changing tags is not that good. I'd rather check in a aversion number then. ;-) This is exactly what we've been doing for Zope 3 releases -- for the same reason. I think it is the one acceptable and reasonable change to a tag. The benefit of forcing us to release from a tag is, imo, significant. Here is a problem that I discussed with Marius earlier today. I often do not know whether all my setup.py settings are correct until I try to upload a release. I frequently get the Development Status classifier wrong and I won't be told it is wrong until I try to register the release. So I usually create the release first and upload it and after that create the tag. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
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 to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Why not leave the version totally out of the setup.py in the trunk? After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We could either leave the version on the branch at the last release or continue the trend of mad bumping and have it at the next release (which since this is a branch, we can actually predict). I prefer the last version, but next would work too. setuptools suggests setting it to the next version. Apart from the fact that it makes more sense to me, the biggest reason I can see is the development egg use case. A development egg from the repository should have a newer version than the latest released egg. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
