[py-dev] towards a 0.8.0 release!

[holger krekel]

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 at 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