Hi Paul, trying to strip it down a bit ... On Sun, Apr 24, 2005 at 21:53 +0100, Paul Moore wrote:
On 4/24/05, holger krekel <hpk@trillke.net> wrote:
And does that mean that the installation and i invoking 'py.test' worked?
Of course not :-) as the file was installed as "py.test" and not as some circumlocution involving a .bat file, or as py.test.py, to be run with that name.
OK, i had the faint and irrational hope that things passed as 'scripts' to setup() would maybe install them appropriately on windows (which shouldn't be impossible to achieve, should it?).
On the other hand, copying the "py.test" script to somewhere else (somewhere on my PATH) and renaming it as, for example, py.test.py, fails with ... Yes, I found it. It's the _findpy.py module again. I stand by my comments from a while back, that the existence of this module is a symptom of a problem. To find the "py" module, you should be doing "import py"!!!
It does fall back to 'import py' these days! Btw, I haven't of heart of problems regarindg _findpy (once you have it properly installed) and it does definitely have advantages at least being a developer, working with different versions.
...
[Meta-comment here - I still get the feeling that there's "too much magic" going on.
Please also understand that i don't currently have access to a win32 platform.
py.test script, and move it anywhere I want, and rename it as I like, and have it still work. That doesn't happen, and that counts as "magic" to me.]
Maybe the _findpy logic should be folded into py.test itself so that it becomes self contained and can easily work with a site-packages installed py lib.
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 ...
Again, not from the installed copy. If it matters, make the version include the Subversion revision number, by all means, but that's all. Unix practice may be different, but on Windows, I'd consider it very bad practice to be working in a directory under "Python24" - ever.
ok, i guess i will be dropping it. In fact i put new "0.8.0-alpha1" installers for unix & windows at http://codespeak.net/download/py They don't contain the '.svn' directories anymore but i am not sure that the windows installer really contains all the files ... Generally, i have to admit that i am just frustrated at the lack of versioning/dependency handling by Python's distribution mechanisms. It has bitten me more than once and i wanted to try out the 'have it svn ready just in case' to get some anchor in it.
... ("C:\Apps\Python24\Removepy.exe" -u "C:\Apps\Python24\py-wininst.log") - the latter is built by the bdist_wininst installer and contains a listing of all the files and directories installed. Doing something like "svn up" from within the site-packages directory would totally break this uninstaller.
Side note: i like the notion of having installed applications completely contained in one directory. That also makes uninstallation trivial.
Perhaps you could explain why you *don't* have an issue with using svn on installed files?
There simply isn't any problem to note from my side. (i am running it on two production machines ...).
Sorry, C-extensions are not built at all currently.
Fair enough. But when you do get it building C extensions, you'll get installer support on Windows "for free" - if setup.py build works, then setup.py bdist_wininst does too. It's pretty slick.
I hope it's feasible to get a win32 build environment for 2.2, and 2.3 and 2.4 on one machine going (and without spending money for licenses ...). cheers, holger