[py-dev] error on trunk in py.path.svn support
Hi there, I just tried the trunk of Py with my project which makes very heavy use of the py.path SVN facilities, and I get a lot of errors that look like this: File "/home/faassen/buildout/z3c.vcsync/py/py/path/svn/wccommand.py", line 270, in status rootstatus = XMLWCStatus(self).fromstring(out, self) File "/home/faassen/buildout/z3c.vcsync/py/py/path/svn/wccommand.py", line 687, in fromstring for c in commitel.getElementsByTagName('author')[0]\ IndexError: list index out of range It looks to me like a certain assumption about the format of the XML returned is incorrect. The SVN version on my system is svn, version 1.4.3 (r23084) When debugging it, the XML that trips up the code looks like this: <entry path="/tmp/pytest-23/wc"> <wc-status item="normal" props="none" revision="0"> <commit revision="0"> <date>2008-08-19T16:50:53.400198Z</date> </commit> </wc-status> </entry> It looks like this means there is not always an 'author' entry in this XML structure. Attached is a patch to wccommand.py that makes the problem go away (and indeed seems to fix the original problem I was looking into - the trunk has support for the svn status flag R, something that py 0.9.1 didn't have). I realize this patch isn't enough but needs a test as well. I could find no obvious way (in the form of documentation, say, the README.txt, or the website) on how to actually run the tests of the trunk. :) It's quite possible I missed something. Is py 0.9.2 to be based off the work on the trunk? Regards, Martijn
Hi Martijn, hum, this probably results from Guido's yesterday merge of his xmlstatus branch ... On Tue, Aug 19, 2008 at 19:02 +0200, Martijn Faassen wrote:
Hi there,
I just tried the trunk of Py with my project which makes very heavy use of the py.path SVN facilities, and I get a lot of errors that look like this:
File "/home/faassen/buildout/z3c.vcsync/py/py/path/svn/wccommand.py", line 270, in status rootstatus = XMLWCStatus(self).fromstring(out, self) File "/home/faassen/buildout/z3c.vcsync/py/py/path/svn/wccommand.py", line 687, in fromstring for c in commitel.getElementsByTagName('author')[0]\ IndexError: list index out of range
It looks to me like a certain assumption about the format of the XML returned is incorrect.
The SVN version on my system is svn, version 1.4.3 (r23084)
When debugging it, the XML that trips up the code looks like this:
<entry path="/tmp/pytest-23/wc"> <wc-status item="normal" props="none" revision="0"> <commit revision="0"> <date>2008-08-19T16:50:53.400198Z</date> </commit> </wc-status> </entry>
It looks like this means there is not always an 'author' entry in this XML structure.
Attached is a patch to wccommand.py that makes the problem go away (and indeed seems to fix the original problem I was looking into - the trunk has support for the svn status flag R, something that py 0.9.1 didn't have).
I realize this patch isn't enough but needs a test as well. I could find no obvious way (in the form of documentation, say, the README.txt, or the website) on how to actually run the tests of the trunk. :) It's quite possible I missed something.
Is py 0.9.2 to be based off the work on the trunk?
yes, 0.9.2 actually mirrors trunk/py/path. If you could submit a test and a fix today or early tomorrow it can definitely go in. (i anyway still am fighting with windows installation issues, sight). as to the tests: if you have "setup.py develop" you should be able to run py.test --runslowtests py/path/svn/testing/test_wccomannd.py or even better :) py.test -n 3 --runslowtests py/path/svn/testing/test_wccomannd.py which doubles test speed on dual-core machines. you can add a test there, i guess one that just feeds a minimal XML string into the method and checks that it groks it fine. oh, and just commit, i'll review the commit (and guido as well, i guess). thanks & best, holger
On Tue, Aug 19, 2008 at 22:52 +0200, Martijn Faassen wrote:
Thanks for the test, Guido!
Regards,
Martijn
thanks to both of you, i merged it to 0.9.x ... and i am still thinking about the way to approach bdist eggs, windows, sdist's and py.* cmdlines ... there *must* a nice solution :) holger
Hi there, Concerning bdist eggs, don't make them unless something should be compiled. If you do need a compiler, make them *only* for the Windows platform. We went to this pattern for all Zope-related eggs and also with lxml and it has worked well. The drawback of binary eggs for any other platform but Windows is that they tend to break under various circumstances if there is compiled code (Python might be compiled with 2 or 4 byte unicode support, for instance). If there *is* no code to compile, the drawback is that the binary egg locks you into whatever Python versions it has been released for. A .tgz works just fine as well with the easy_install tools and buildout and works without them too. This describes the Zope-related release procedure: http://grok.zope.org/documentation/how-to/releasing-software So, the rule: python setup.py register sdist upload for any egg unless you have compiled extensions and you're releasing a Windows egg. Concerning command-line scripts I'm not sure I can help. I use (I believe setuptools) support for entry_points: 'console_scripts': { 'scriptname = foo.bar:mainfunc', ] }, with default easy_install that causes scripts to end up in /usr/bin, but with buildout, these scripts end up in a 'bin' subdirectory (or whatever your configuration is) of the buildout direcory (which is by default the project directory which contains setup.py). (for other scripts not directly supplied by the package such as for instance a test runner itself I use various buildout recipes to create them. I'm not sure whether that's relevant here) Regards, Martijn
On Wed, Aug 20, 2008 at 2:52 PM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
Concerning bdist eggs, don't make them unless something should be compiled. If you do need a compiler, make them *only* for the Windows platform.
Isn't it safe to build eggs for OS X? Did you run into problems with that? Regards, - Ralf
Hi there, On Wed, Aug 20, 2008 at 3:27 PM, Ralf Schmitt <schmir@gmail.com> wrote:
On Wed, Aug 20, 2008 at 2:52 PM, Martijn Faassen <faassen@startifact.com> wrote:
Concerning bdist eggs, don't make them unless something should be compiled. If you do need a compiler, make them *only* for the Windows platform.
Isn't it safe to build eggs for OS X? Did you run into problems with that?
I don't use OS X as my primary development platform, but people who *do* use OS X have recommended this practice. Anyway, I'd expect problems, as from what I've seen of OS X it is very frequent people install non-system Pythons on it, in a variety of ways (fink, darwinports, etc). Regards, Martijn
Hi Martijn, On Wed, Aug 20, 2008 at 14:52 +0200, Martijn Faassen wrote:
Concerning bdist eggs, don't make them unless something should be compiled. If you do need a compiler, make them *only* for the Windows platform.
We went to this pattern for all Zope-related eggs and also with lxml and it has worked well.
yip, i am using that as well.
The drawback of binary eggs for any other platform but Windows is that they tend to break under various circumstances if there is compiled code (Python might be compiled with 2 or 4 byte unicode support, for instance). If there *is* no code to compile, the drawback is that the binary egg locks you into whatever Python versions it has been released for. A .tgz works just fine as well with the easy_install tools and buildout and works without them too.
This describes the Zope-related release procedure:
http://grok.zope.org/documentation/how-to/releasing-software
thanks, nice doc.
So, the rule:
python setup.py register sdist upload
for any egg unless you have compiled extensions and you're releasing a Windows egg.
ok. py lib has the greenlet extension so this requires bdist_egg from windows. so, now i am trying to also get "easy_install py==dev" to work. I tried having a setup.cfg of [egg_info] tag_build = .dev tag_svn_revision = 1 and with a "version=1.0.0.a1" in setup.py and calling python setup.py sdist upload this registered and uploaded a 1.0.0a1-r57529 version fine. But then "easy_install py" on another machine gave me the dev version instead of the release (0.9.2b7 currently). What am i missing? (i removed the 1.0.0a1 completely from pypi, btw).
Concerning command-line scripts I'm not sure I can help. I use (I believe setuptools) support for entry_points:
'console_scripts': { 'scriptname = foo.bar:mainfunc', ] },
py lib is using that as well now.
with default easy_install that causes scripts to end up in /usr/bin, but with buildout, these scripts end up in a 'bin' subdirectory (or whatever your configuration is) of the buildout direcory (which is by default the project directory which contains setup.py).
yip, same with virtualenv.
(for other scripts not directly supplied by the package such as for instance a test runner itself I use various buildout recipes to create them. I'm not sure whether that's relevant here)
i guess i am still learning how to deal conveniently with setuptools ... holger
Hi there, [snip]
so, now i am trying to also get "easy_install py==dev" to work. I tried having a setup.cfg of
[egg_info] tag_build = .dev tag_svn_revision = 1
and with a "version=1.0.0.a1" in setup.py and calling
python setup.py sdist upload
this registered and uploaded a 1.0.0a1-r57529 version fine.
Ugly. In the Zope community we've been avoiding any setup.cfg and we've done actual proper releases whenever needed. We used to produce a lot of those ugly -r515153 eggs, but for a large system composed out of multiple packages such a "release but not really a proper release" things were far more pain than they're worth, as the releases didn't tend to be very well managed.
But then "easy_install py" on another machine gave me the dev version instead of the release (0.9.2b7 currently). What am i missing?
Hm, I don't know off the top of my head, I'm afraid.
(i removed the 1.0.0a1 completely from pypi, btw).
Removing released eggs is also not a good idea to do very often. We have a policy that we never remove anything from PyPI but just make a new, later, release. People may be depending on the versions on PyPI - automatic build systems may pull in an egg before you know it, after all. I'm just sketching out what I know from our Zope egg release mill here. Other approaches may of course work too, I'm just telling you what works for us (and the bits I know). Regards, Martijn
participants (4)
-
Guido Wesdorp -
holger krekel -
Martijn Faassen -
Ralf Schmitt