Andreas Jung wrote:
make sdist:
ajung@sentinel:~/sandboxes/Zope-2.9/2.9.0b1: make sdist zpkg -C /develop/sandboxes/Zope-2.9/2.9.0b1/releases/Zope2.cfg 'version.txt' doesn't match any files in <collection> (in /develop/sandboxes/Zope-2.9/2.9.0b1/lib/python/zope/app/PACKAGE.cfg) ---- temporary files are in /tmp/zpkg-50vtPj make: *** [sdist] Error 1
This is a very recent problem and a result of Jim's inconsistent handling of the "version.txt" matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch. The Zope 2.9 externals currently point to the Zope 3.2 branch which references version.txt in PACKAGE.cfg but doesn't have one. Only the 3.2.0beta1 tag has it. I think that a) zope.app/PACKAGE.cfg should not mention version.txt when there isn't one, meaning on the branch b) Zope 2.9 externals should now point to the Zope 3.2.0beta1 tag. By the way, this issue reminds me: We haven't figured out how to handle Zope 2's version.txt at all! I totally forgot about it. Zope 2 expects a version.txt in Zope/lib/python, but zpkg has no way to support a data file that isn't in a Python package. So there would be no way to package it nor to install it (I don't think distutils knows how to install a non-package-related datafile either). I propose that the future place for Zope 2's version.txt is the Zope2 package. Some code inside Zope 2 that reads version info from version.txt would have to be changed for that, though. This should be fixed for the 2.9 beta, meaning today. I'm outside svn+ssh access range right now, so either you do it, Andreas, or you wait until I'm at home in about 5 hours. Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Philipp von Weitershausen wrote:
Andreas Jung wrote:
make sdist:
ajung@sentinel:~/sandboxes/Zope-2.9/2.9.0b1: make sdist zpkg -C /develop/sandboxes/Zope-2.9/2.9.0b1/releases/Zope2.cfg 'version.txt' doesn't match any files in <collection> (in /develop/sandboxes/Zope-2.9/2.9.0b1/lib/python/zope/app/PACKAGE.cfg) ---- temporary files are in /tmp/zpkg-50vtPj make: *** [sdist] Error 1
This is a very recent problem and a result of Jim's inconsistent handling of the "version.txt" matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch.
Yeah, I was trying to minimize the amount of work done on a tag. It didn't occur to me that this would affect Z2. :( In the future, we need to come up with a better way to handle this.
The Zope 2.9 externals currently point to the Zope 3.2 branch which references version.txt in PACKAGE.cfg but doesn't have one. Only the 3.2.0beta1 tag has it. I think that
a) zope.app/PACKAGE.cfg should not mention version.txt when there isn't one, meaning on the branch
b) Zope 2.9 externals should now point to the Zope 3.2.0beta1 tag.
I guess this would solve the problem, since the tag does have a version.txt.
By the way, this issue reminds me: We haven't figured out how to handle Zope 2's version.txt at all! I totally forgot about it. Zope 2 expects a version.txt in Zope/lib/python, but zpkg has no way to support a data file that isn't in a Python package.
And there's the fact that this is a file that really *should* be generated by the release process.
So there would be no way to package it nor to install it (I don't think distutils knows how to install a non-package-related datafile either).
I propose that the future place for Zope 2's version.txt is the Zope2 package. Some code inside Zope 2 that reads version info from version.txt would have to be changed for that, though. This should be fixed for the 2.9 beta, meaning today. I'm outside svn+ssh access range right now, so either you do it, Andreas, or you wait until I'm at home in about 5 hours.
I agree, this should be doen for this release. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
This is a very recent problem and a result of Jim's inconsistent handling of the "version.txt" matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch.
Yeah, I was trying to minimize the amount of work done on a tag. It didn't occur to me that this would affect Z2. :( In the future, we need to come up with a better way to handle this.
I wouldn't dare to mention my suggestions regarding issues like these... ;)
The Zope 2.9 externals currently point to the Zope 3.2 branch which references version.txt in PACKAGE.cfg but doesn't have one. Only the 3.2.0beta1 tag has it. I think that
a) zope.app/PACKAGE.cfg should not mention version.txt when there isn't one, meaning on the branch
b) Zope 2.9 externals should now point to the Zope 3.2.0beta1 tag.
I guess this would solve the problem, since the tag does have a version.txt.
Yup, it does solve the problem.
By the way, this issue reminds me: We haven't figured out how to handle Zope 2's version.txt at all! I totally forgot about it. Zope 2 expects a version.txt in Zope/lib/python, but zpkg has no way to support a data file that isn't in a Python package.
And there's the fact that this is a file that really *should* be generated by the release process.
Yes. It sort of is already now. When you check out a Zope 2 tag and run "make sdist" to create the tarball, it will first generate the version.txt and put it in the right place.
So there would be no way to package it nor to install it (I don't think distutils knows how to install a non-package-related datafile either).
I propose that the future place for Zope 2's version.txt is the Zope2 package. Some code inside Zope 2 that reads version info from version.txt would have to be changed for that, though. This should be fixed for the 2.9 beta, meaning today. I'm outside svn+ssh access range right now, so either you do it, Andreas, or you wait until I'm at home in about 5 hours.
I agree, this should be doen for this release.
Done in r40592 on Zope 2.9 branch. Philipp
Philipp von Weitershausen wrote:
Jim Fulton wrote:
This is a very recent problem and a result of Jim's inconsistent handling of the "version.txt" matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch.
Yeah, I was trying to minimize the amount of work done on a tag. It didn't occur to me that this would affect Z2. :( In the future, we need to come up with a better way to handle this.
I wouldn't dare to mention my suggestions regarding issues like these... ;)
A common tree wouldn't make a difference here. A common release process would. Actually, a suggestion of Stephan's would make a difference. It would have helped someone if releases were regularly tested. Stephan has suggested that he'd like like buildbot to build releases as part of it's tests. I'd like to get there too. Unfortunately, we still need to resolve some technical issues to make this possible.
The Zope 2.9 externals currently point to the Zope 3.2 branch which references version.txt in PACKAGE.cfg but doesn't have one. Only the 3.2.0beta1 tag has it. I think that
a) zope.app/PACKAGE.cfg should not mention version.txt when there isn't one, meaning on the branch
b) Zope 2.9 externals should now point to the Zope 3.2.0beta1 tag.
I guess this would solve the problem, since the tag does have a version.txt.
Yup, it does solve the problem.
By the way, this issue reminds me: We haven't figured out how to handle Zope 2's version.txt at all! I totally forgot about it. Zope 2 expects a version.txt in Zope/lib/python, but zpkg has no way to support a data file that isn't in a Python package.
And there's the fact that this is a file that really *should* be generated by the release process.
Yes. It sort of is already now. When you check out a Zope 2 tag and run "make sdist" to create the tarball, it will first generate the version.txt and put it in the right place.
Cool
So there would be no way to package it nor to install it (I don't think distutils knows how to install a non-package-related datafile either).
I propose that the future place for Zope 2's version.txt is the Zope2 package. Some code inside Zope 2 that reads version info from version.txt would have to be changed for that, though. This should be fixed for the 2.9 beta, meaning today. I'm outside svn+ssh access range right now, so either you do it, Andreas, or you wait until I'm at home in about 5 hours.
I agree, this should be doen for this release.
Done in r40592 on Zope 2.9 branch.
Thanks! Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
This is a very recent problem and a result of Jim's inconsistent handling of the "version.txt" matter yesterday. http://dev.zope.org/Zope3/MakingARelease says that zope.app/version.txt should be created on a tag and zope.app/PACKAGE.cfg should also be modified to include version.txt *on the tag*. Jim did the latter on the Zope 3.2 branch.
Yeah, I was trying to minimize the amount of work done on a tag. It didn't occur to me that this would affect Z2. :( In the future, we need to come up with a better way to handle this.
I wouldn't dare to mention my suggestions regarding issues like these... ;)
A common tree wouldn't make a difference here. A common release process would.
My feeling is that common tree => common processes. But I'm not going to get into another discussion like we've had before, so I take your point on this not making a difference for granted.
Actually, a suggestion of Stephan's would make a difference. It would have helped someone if releases were regularly tested. Stephan has suggested that he'd like like buildbot to build releases as part of it's tests. I'd like to get there too. Unfortunately, we still need to resolve some technical issues to make this possible.
Buildbot is awesome and Stephan's suggestion is a excellent one. However, I consider buildbot a good safety-belt, not more. It's definitely not an excuse for not testing things properly in a local sandbox before checking in. Having it tested in *some* way at least, whether buildbot or not, would already be a huge improvement, of course. Philipp
Philipp von Weitershausen wrote:
Jim Fulton wrote:
...
Buildbot is awesome and Stephan's suggestion is a excellent one. However, I consider buildbot a good safety-belt, not more. It's definitely not an excuse for not testing things properly in a local sandbox before checking in.
There's a limit to how mech we can test on every checkin. The tests we do run already take several minutes to run. It's just not practical to test everything on every checkout.
Having it tested in *some* way at least, whether buildbot or not, would already be a huge improvement, of course.
Yup. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (2)
-
Jim Fulton -
Philipp von Weitershausen