[py-dev] towards a 0.8.0 release!
Hi folks, a few notes and questions regarding the to-be-released py lib, named '0.8.0': - there now is a setup.py in the 'svn/py/dist' directory which should work at least on unix-ish systems. Note that the "setup install" command will basically install the whole tree of the py lib including all svn-control files. This means that you can go to '../python-2.X/site-packages/py' and issue 'svn up'. It also means that when you fix things, you can run 'svn diff' there to create a patch. Or, if you have a codespeak account you can branch easily to test some idea out etc.pp. - the main missing piece is testing things much more on windows (speaking of which: has anyone recently used py.test on win32 and could try out: python py/bin/py.test py and possibly python setup.py install that would be great. I am sure that at least the installation of 'py.test' as a script will not work and i have not clue how to do it myself. Brian Dorsey suggested in private conversation to write an Immo binary Installer. - when 0.8.0 comes out, i basically want the directory release layout to look like this: http://codespeak.net/py/current/doc/releasescheme.html this means in particular: * svn/py/trunk will then hold head development * svn/py/branch/0.8 will be the ongoing release branch * svn/py/tag/0.8.x will be a tagged release * svn/py/dist will always hold the newest release and will not be writeable/commitable most of the time (i'll also prevent commits to 'tag/', i guess) - until 1.0 there will be _no_ particular release guarantees but i will be trying to follow and refine: http://codespeak.net/py/current/doc/why_py.html#upcoming-release-policy-api-... - i'd like to have 1.0 latest at EuroPython end of June feedback & help welcome, holger
On 23/04/05, holger krekel <hpk@trillke.net> wrote:
Hi folks, <snip> - the main missing piece is testing things much more on windows (speaking of which: has anyone recently used py.test on win32 and could try out:
python py/bin/py.test py
This mostly passes for me on my home Windows XP machine. Only two of the tests give errors, but they give lots of them. py/path/svn/testing/test_urlcommand.py[73] FFF.F.........FFF..FFFFFFF...FFFFFFFF F.FFF......FFFFFFF.FFF.FFFFFFFF.FFFF py/path/svn/testing/test_wccommand.py[85] FFFFFFFFFFF...FFFFF.......F........FFF ...F I'm seeing lots of errors like this: Error: [None]: svn: Unrecognized URL scheme ''file://c%3A%5Cdocume%7E1%5Cbrian%5Clocals%7E1%5Ctemp%5Cpytest-0%5Crepo/otherdir'' So I may have an old or different version of svn installed. I'll see if I can track down the failures. That said... I'm probably not a normal windows user... I doubt most windows users even have svn in their path. ;)
and possibly
python setup.py install
I'll try to look at this soon... but it may not happen... life has gotten busy for me again. :)
that would be great. I am sure that at least the installation of 'py.test' as a script will not work and i have not clue how to do it myself. Brian Dorsey suggested in private conversation to write an Immo binary Installer.
I was thinking of Inno Setup: http://www.jrsoftware.org/isinfo.php ... that said... if we can get the standard distutils version working, that's probably the best? This is a bit new to me as well... I've never really distributed python modules for windows, just applications. (That said... the module installers I have used which also have scripts never seem to just work for me. :) Take care, -Brian
On 4/24/05, Brian Dorsey <briandorsey@gmail.com> wrote:
I was thinking of Inno Setup: http://www.jrsoftware.org/isinfo.php ... that said... if we can get the standard distutils version working, that's probably the best? This is a bit new to me as well... I've never really distributed python modules for windows, just applications. (That said... the module installers I have used which also have scripts never seem to just work for me. :)
I'd very strongly recommend sticking with a standard setup.py/bdist_wininst installer for Windows. It's what nearly every other package uses. I just did a quick test of bdist_wininst and it failed to tidy up properly, I think largely because it couldn't remove the Subversion directories. I strongly disagree with the idea of including the Subversion control stuff in the installed copy, in any case. In my view, you shouldn't be doing "svn up" in your site-packages tree, rather you should be doing it in your build tree, then building a new installer and running it. This keeps the registry of installed packages up to date. Of course, on Unix where there is no uninstall facility (if you puse setup.py install, at least) this is less of an issue, but it is true on Windows. Is there any chance of changing the decision to include the .svn directories - on Windows, if not elsewhere? Other issues with setup.py - it doesn't seem to build C extensions - greenlets, specifically, but I notice that popen5 (_subprocess.c) is included as well - is this right? If so, I'd expect it to be excluded from Python 2.4 and above builds (which is problematic as long as there are no C extensions included, as in that case the installer is version-independent). Sorry, but I'm not able to go much further with this at the moment. I hope the above comments are of some help in any case. Paul.
Hi Paul, On Sun, Apr 24, 2005 at 20:22 +0100, Paul Moore wrote:
I just did a quick test of bdist_wininst and it failed to tidy up properly, I think largely because it couldn't remove the Subversion directories.
What exactly failed? The .svn-directories are installled as data files so i am curious why it doesn't work. And does that mean that the installation and i invoking 'py.test' worked?
I strongly disagree with the idea of including the Subversion control stuff in the installed copy, in any case. In my view, you shouldn't be doing "svn up" in your site-packages tree,
.. it's also 'svn info' and 'svn diff' that is useful IMO ...
rather you should be doing it in your build tree, then building a new installer and running it.
That should of course work but it's not neccessarily excluding the other approach.
This keeps the registry of installed packages up to date.
I guess you are refering to the Windows registry, right? What information is in there exactly? Like a list of packages with versions and the list of installed files or some such?
Of course, on Unix where there is no uninstall facility (if you puse setup.py install, at least) this is less of an issue, but it is true on Windows.
Is there any chance of changing the decision to include the .svn directories - on Windows, if not elsewhere?
Yes, there are chances. I'd like to understand the problems better, though. Doing things too differently on windows and unix is certainly undesirable.
Other issues with setup.py - it doesn't seem to build C extensions - greenlets, specifically,
Sorry, C-extensions are not built at all currently.
but I notice that popen5 (_subprocess.c) is included as well - is this right?
Yes, the py lib aims to run on python 2.2 upwards.
If so, I'd expect it to be excluded from Python 2.4 and above builds (which is problematic as long as there are no C extensions included, as in that case the installer is version-independent).
Indeed, greenlets & subprocess will probably make the installer version dependent, i am afraid. Is it black magic to build version dependent installers or is it rather straight forward?
Sorry, but I'm not able to go much further with this at the moment. I hope the above comments are of some help in any case.
Yes, thanks a lot! holger
On Sun, 24 Apr 2005 22:07:21 +0200, holger krekel <hpk@trillke.net> wrote:
Indeed, greenlets & subprocess will probably make the installer version dependent, i am afraid. Is it black magic to build version dependent installers or is it rather straight forward?
As soon as you compile C extensions, you will get an installer which is only for the python version used to build the installer. So to build an python 2.3 installer you run it with python 2.3 etc. Regards, Florian Schulze
Hi Brian! On Sun, Apr 24, 2005 at 11:50 -0700, Brian Dorsey wrote:
On 23/04/05, holger krekel <hpk@trillke.net> wrote:
Hi folks, <snip> - the main missing piece is testing things much more on windows (speaking of which: has anyone recently used py.test on win32 and could try out:
python py/bin/py.test py
This mostly passes for me on my home Windows XP machine. Only two of the tests give errors, but they give lots of them.
py/path/svn/testing/test_urlcommand.py[73] FFF.F.........FFF..FFFFFFF...FFFFFFFF F.FFF......FFFFFFF.FFF.FFFFFFFF.FFFF py/path/svn/testing/test_wccommand.py[85] FFFFFFFFFFF...FFFFF.......F........FFF ...F
I'm seeing lots of errors like this: Error: [None]: svn: Unrecognized URL scheme ''file://c%3A%5Cdocume%7E1%5Cbrian%5Clocals%7E1%5Ctemp%5Cpytest-0%5Crepo/otherdir''
So I may have an old or different version of svn installed.
Quite likely, it's a problem of command line parsing / escaping things properly.
I'll see if I can track down the failures.
That said... I'm probably not a normal windows user... I doubt most windows users even have svn in their path. ;)
Hum, i see. What is a proper way to get at the location of such a binary on win32? cheers & thanks, holger
On Sun, Apr 24, 2005 at 22:10 +0200, holger krekel wrote:
On Sun, Apr 24, 2005 at 11:50 -0700, Brian Dorsey wrote:
That said... I'm probably not a normal windows user... I doubt most windows users even have svn in their path. ;)
Hum, i see. What is a proper way to get at the location of such a binary on win32?
The canonical way would be to look for certain popular ssh implementations in the registry about their install location. But accessing the registry requires the win32 python extensions, which are optional as well. And then the binary might not even be named ssh, for example with the popular PuTTY package the command line remote exec utility is named plink.exe. -- Jens-Uwe Mager <pgp-mailto:F476EBC2>
On 4/24/05, holger krekel <hpk@trillke.net> wrote:
Hum, i see. What is a proper way to get at the location of such a binary on win32?
Assume it's in PATH. If it isn't, there's no "proper" way. Actually, don't even assume that. I might well have a "svn.bat" in my path, which executes svn.exe from a particular directory. Just assume the command "svn" will work, and handle exceptions gracefully. (Is my hardline attitude becoming clear yet? :-)) Paul. PS I'm not actually sure this is the real issue here. That file: URL quoted looks distinctly odd - possibly legal, but definitely odd. Windows programs have "interesting" views on valid forms of file URLs (I don't what to go into details here, I'd end up defending a complex mess as being pragmatically the right thing...) PPS FWIW, I got similar patterns of failures in the two tests quoted, but no mention of odd URLs. I'm not going to post the error tracebacks, as there were a lot (the second was 868 lines) and I have no time to even try to help diagnose the issue. I'd also point out that when I ran the full test, the execnet stuff seemed to hang, but I don't know why.
On Apr 24, 2005, at 5:28 PM, Paul Moore wrote:
On 4/24/05, holger krekel <hpk@trillke.net> wrote:
Hum, i see. What is a proper way to get at the location of such a binary on win32?
Assume it's in PATH. If it isn't, there's no "proper" way. Actually, don't even assume that. I might well have a "svn.bat" in my path, which executes svn.exe from a particular directory. Just assume the command "svn" will work, and handle exceptions gracefully.
Why not look in the registry for hints that the win32 installer for svn was used, and if so, use that? -bob
On 24/04/05, holger krekel <hpk@trillke.net> wrote:
I'm seeing lots of errors like this: Error: [None]: svn: Unrecognized URL scheme ''file://c%3A%5Cdocume%7E1%5Cbrian%5Clocals%7E1%5Ctemp%5Cpytest-0%5Crepo/otherdir''
So I may have an old or different version of svn installed.
Quite likely, it's a problem of command line parsing / escaping things properly.
OK, I didn't have much time to look at this carefullly, but there is at least a problem with the escaping of quotes on the command line, and even after doing what I think should resolve that, it doesn't seem to like all the URL safety '%' in the path. I get things like this back from svn: D:\BrianDocuments\home\local\py-dist> svn ls "-v" file://c%3A%5Cdocume%7E1%5Cbri an%5Clocals%7E1%5Ctemp%5Cpytest-1%5Crepo/otherdir svn: Unable to open an ra_local session to URL svn: Local URL 'file://c%3A%5Cdocume%7E1%5Cbrian%5Clocals%7E1%5Ctemp%5Cpytest-1% 5Crepo/otherdir' contains unsupported hostname I've run out of time to play with this today (and, honestly, didn't get to spend that much time on it. ;) but, I'd like to present one option for the 0.8 release: The py.test funtionality is the most important to me, (and perhaps generally?) and it wouldn't bother me even the tiniest little bit if none of the C modules, SVN magic or anything except py.test didn't work on Windows for this release. ;)
That said... I'm probably not a normal windows user... I doubt most windows users even have svn in their path. ;)
Hum, i see. What is a proper way to get at the location of such a binary on win32?
I'm with Paul on this one. If it's not in the path, don't do svn stuff. If the user wants to do svn stuff, make them modify their path and point to the copy of svn that they want to use. (actually... I'll bet most windows users... even most python users probably don't have svn even installed.) Take care, -Brian
Brian Dorsey wrote:
On 24/04/05, holger krekel <hpk@trillke.net> wrote:
I'm seeing lots of errors like this: Error: [None]: svn: Unrecognized URL scheme ''file://c%3A%5Cdocume%7E1%5Cbrian%5Clocals%7E1%5Ctemp%5Cpytest-0%5Crepo/otherdir''
So I may have an old or different version of svn installed.
Quite likely, it's a problem of command line parsing / escaping things properly.
OK, I didn't have much time to look at this carefullly, but there is at least a problem with the escaping of quotes on the command line, and even after doing what I think should resolve that, it doesn't seem to like all the URL safety '%' in the path. I get things like this back from svn: D:\BrianDocuments\home\local\py-dist> svn ls "-v" file://c%3A%5Cdocume%7E1%5Cbri an%5Clocals%7E1%5Ctemp%5Cpytest-1%5Crepo/otherdir svn: Unable to open an ra_local session to URL svn: Local URL 'file://c%3A%5Cdocume%7E1%5Cbrian%5Clocals%7E1%5Ctemp%5Cpytest-1% 5Crepo/otherdir' contains unsupported hostname
well the first thing I notice is file:// instead of file:///, maybe it works on Unix with two slashes but the file: protocol really needs three, I remember on windows this being quite important because of the drive thing. Or file://localhost/. See also http://svnbook.red-bean.com/en/1.0/ch02s03.html#svn-ch-2-table-1 And you probably don't want back-slashes even % encoded, but just slashes.
Samuele Pedroni wrote:
well the first thing I notice is file:// instead of file:///, maybe it works on Unix with two slashes but the file: protocol really needs three, I remember on windows this being quite important because of the drive thing. Or file://localhost/. See also
http://svnbook.red-bean.com/en/1.0/ch02s03.html#svn-ch-2-table-1
And you probably don't want back-slashes even % encoded, but just slashes.
indeed reading the relevant specs % encoding can be used inside path segments (that means what is between // slashes) but the segments themself need to separated by plain unencoded slashes.
participants (8)
-
Bob Ippolito -
Brian Dorsey -
Florian Schulze -
holger krekel -
hpk＠trillke.net
-
Jens-Uwe Mager -
Paul Moore -
Samuele Pedroni