[py-dev] error on trunk in py.path.svn support

[holger krekel]

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