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 _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
