Mailman 3 July 2007 - Distutils-SIG

cross-compiling using distutils
by Mark Hammond July 17, 2007

July 17, 2007

Hi all, I'm making good progress on using bdist_msi to package up x64 versions of the pywin32 extensions. On the way I've struck a number of issues. In an effort to try and keey the discussions focussed, I'll create new threads for each of them, and the first cab off the rank is cross-compilation. IIUC, the only way to build Python or Python extensions using VS2003 is to cross-compile from a 32bit platform. Although this requirement is only short term, in the longer term we should support cross-compilation to prevent a Windows developer needing access to all architectures just to create a build. Here are the problems I had: * The dev box needs access to both a 32bit and a 64bit version of Python - the 32bit one to execute Python itself, and the 64bit one to link against. * PYTHONHOME had to be set to the x64 version of Python when running the build, otherwise the link would fail as it tries to use the 32bit python.lib * '/MACHINE:AMD64' or '/MACHINE:Itanium' manually needs to be added to the link commandline. * '/D_M_X64' had to be passed to the compiler (which seems unusual, but I didn't dig too deep into this) One way to approach this might be to add a "global" option to distutils. It might be possible to call it --python_bin_dir, which would point at the libraries for the target system (and we could attempt to sniff the architecture from them). It would need to be a 'global' option as many commands may need to know the target (eg, bdist_msi would also need to know) and distutils.util.get_platform() would need to change to reflect the target platform, not the platform being used to perform the build. msvccompiler.get_build_architecture() could also change to take advantage of this and grow support for /MACHINE etc. Does anyone have any thoughts on this? I'm happy to come up with a patch, but I'm looking for direction (or even just encouragement <wink>) Thanks, Mark

1 0

unattended install
by vadim suvorov July 17, 2007

July 17, 2007

I have a customer who has many (Windows) computers on which Python and related packages must be installed/updated on regular bases. One of their concerns is wininst based packages, which do not allow unattended installation. Newer and greater MSI helps, but there are legacy packages. Can you give me opinion: 1) Why pywin32 (Mark Hammond) is continued to be distributed in wininst form? 2) If one prepares MSI package, are there foreseeable snags to distribute it in 2.4 environment? 3) I offered to consider development of wininst to msi (ready package) converter. Is it stupid suggestion, or is it feasable (and easier than silencing of wininst)? Would there be interest for such converter (my customer is willing to contribute to Python project)? Thank you!

2 4

[easy_install] won't upgrade egg from 1.0.9 -> 1.0.10
by Andreas Jung July 17, 2007

July 17, 2007

I uploaded z3c.sqlalchemy 1.0.10 to Cheeseshop. easy_install -U z3c.sqlalchemy won't upgrade an installed 1.0.9 egg to the new version unless I pass the current version as "z3c.sqlalchemy==1.0.10". Bug or feature? Andreas

2 1

Newbie questions about setuptools
by Edward Ream July 16, 2007

July 16, 2007

I have some questions and comments about setuptools and easy_install. What I like best about setuptools is that setup eliminates the need to maintain manifest.in and MANIFEST files. Assuming that everything in the cvs tree is part of the distribution is a clever idea, and it works for me. This is reason enough for me to want to use setuptools. However, I have the following problems with setuptools. These are serious enough so that for now I just use setuptools to create .zip files. 1. On both XP and Ubuntu, running python setup.py bdist_egg gives a .egg file with a suffix of py2.5.egg, even though the version arg to setup is '4.4.3preview9' I was expecting a suffix of all.egg, because platforms = ['all',] Can anyone explain what is going on? Here is the complete call to setup: setuptools.setup ( name='leo', version='4.4.3preview9', author='Edward K. Ream', author_email='edreamleo(a)charter.net', url='http://webpages.charter.net/edreamleo/front.html', download_url='http://downloads.sourceforge.net/leo/leo-4.4.3preview9.egg', packages = setuptools.find_packages(), include_package_data = True, exclude_package_data = { '': ['*.pyc','*.pyo']}, zip_safe=False, install_requires=[], description = 'Leo: Literate Editor with Outlines', license='Python', platforms=['all',], long_description = long_description, keywords = 'outline, outliner, ide, editor, literate programming', ) 2. The resulting egg file is much larger than the .zip file created by 'python setup.py sdist' in spite of exclude_package_data = { '': ['*.pyc','*.pyo']}, Is there any way to exclude .pyc and .pyo files? 3. 'python setup.py register' works fine, but 'python setup.py upload' fails with an 'invalid request' returned from the server. Maybe because the egg is over 8Meg? 4. 'easy_install leo' is supposed to use the download_url link arg. This is a great idea. Alas, for me it is spoiled by the setuptools pre/post release naming convention. The problem is that this convention is applied to all the links on the download_url page. Because I can't upload to the Python Cheese Shop, I used Leo's SourceForge download page for the main Leo project. The setup.py script is supposed to find the latest release on the page, but setup.py thinks that the latest match is something like Leo-4.2.1.zip (!!) This in spite of the fact that Leo-4.4.3rc1.zip exists on the page. I can't change the filenames on Leo's SourceForge page, and I can't change setuptools's naming conventions. How is 'easy_install leo' going to find the proper version? 5. setuptools is advertised as an 0.x release. This post appeared over a year ago, http://bitworking.org/news/Please_stop_using_setuptools__at_least_exclusive… This post may be obsolete, but it troubles me. I suppose I wouldn't worry so much were it not for these other issues. Any help would be greatly appreciated. Thanks. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

5 16

Empty directories in eggs
by Martin Aspeli July 15, 2007

July 15, 2007

Hi, I tried to build an egg from this tag, using bdist_egg and sdist: http://svn.plone.org/svn/collective/ZopeSkel/tags/0.5/ However, the packaged egg lost several directories, such as: http://svn.plone.org/svn/collective/ZopeSkel/tags/0.5/zopeskel/templates/pl… These are empty, but under version control. To get them into the egg (I need it because it's part of a Paste Script template which expects the empty directories to be there), I had to add some mostly-empty (if slightly useful) README.txt files (on the 0.6 tag). Bug or feature? ;-) Martin -- Acquisition is a jealous mistress

1 0

Buildout error reporting - connection refused
by Martin Aspeli July 15, 2007

July 15, 2007

Hi Jim & co, I just ran a buildout and got this error. It went away again (I guess it was a server going down), but it annoyed me that I couldn't work out *which* URL it was trying to connect to that got refused. Could buildout produce a bit more information in this case? Also - I had a find-link at this point that I know was down. It is not the link for python-openid, so it shouldn't matter, it's only a backup mirror (which atm is even empty). But would setuptools/buildout bomb out regardless, if one of the find-links was down? Thanks, Martin $ ./bin/buildout -vv Installing 'zc.buildout', 'setuptools'. We have the best distribution that satisfies 'zc.buildout'. Picked: zc.buildout = 1.0.0b28 We have the best distribution that satisfies 'setuptools'. Picked: setuptools = 0.6c6 Installing 'plone.recipe.plone'. We have the best distribution that satisfies 'plone.recipe.plone'. Adding find link 'http://download.zope.org/distribution/' from plone.recipe.plone 3.0rc1 Picked: plone.recipe.plone = 3.0rc1 Getting required 'plone.recipe.distros' required by plone.recipe.plone 3.0rc1. We have the best distribution that satisfies 'plone.recipe.distros'. Picked: plone.recipe.distros = 0.2 Getting required 'zc.recipe.egg' required by plone.recipe.plone 3.0rc1. We have the best distribution that satisfies 'zc.recipe.egg'. Picked: zc.recipe.egg = 1.0.0b6 Installing 'plone.recipe.zope2install'. We have the best distribution that satisfies 'plone.recipe.zope2install'. Adding find link 'http://download.zope.org/distribution/' from plone.recipe.zope2install 0.1 Picked: plone.recipe.zope2install = 0.1 Installing 'plone.recipe.zope2instance'. We have the best distribution that satisfies 'plone.recipe.zope2instance'. Adding find link 'http://download.zope.org/distribution/' from plone.recipe.zope2instance 0.6.1 Picked: plone.recipe.zope2instance = 0.6.1 Configuration data: [zope2] executable = /opt/local/Library/Frameworks/Python.framework/Versions/2.4/bin/python location = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/zope2 recipe = plone.recipe.zope2install url = http://www.zope.org/Products/Zope/2.10.4/Zope-2.10.4-final.tgz [buildout] bin-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/bin develop = develop-eggs-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/develop-eggs directory = /Users/optilude/tmp/eggs/zopeskel/rc1 download-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/downloads eggs = eggs-directory = /Users/optilude/.buildout/eggs executable = /opt/local/Library/Frameworks/Python.framework/Versions/2.4/bin/python find-links = installed = /Users/optilude/tmp/eggs/zopeskel/rc1/.installed.cfg log-format = log-level = INFO newest = true offline = false parts = %(__buildout_space_n__)splone zope2 productdistros instance zopepy parts-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/parts python = buildout verbosity = 20 [productdistros] location = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/productdistros nested-packages = prefix = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/productdistros recipe = plone.recipe.distros urls = version-suffix-packages = [instance] _b = /Users/optilude/tmp/eggs/zopeskel/rc1/bin _d = /Users/optilude/tmp/eggs/zopeskel/rc1/develop-eggs _e = /Users/optilude/.buildout/eggs bin-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/bin debug-mode = on develop-eggs-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/develop-eggs eggs = %(__buildout_space_n__)s%(__buildout_space_n__)sarchetypes.kss==1.2-rc1.1 kss.core==1.2-rc1.1 plone.app.content==1.0rc1 plone.app.contentmenu==1.0rc1 plone.app.contentrules==1.0rc1 plone.app.controlpanel==1.0rc1 plone.app.customerize==1.0rc1 plone.app.form==1.0rc1 plone.app.i18n==1.0rc1 plone.app.iterate==1.0rc1 plone.app.kss==1.2-rc1.1 plone.app.layout==1.0rc1 plone.app.linkintegrity==1.0rc1.1 plone.app.openid==1.0rc1 plone.app.portlets==1.0rc1 plone.app.redirector==1.0rc1 plone.app.viewletmanager==1.0rc1 plone.app.vocabularies==1.0rc1 plone.app.workflow==1.0rc1 plone.contentrules==1.0rc1 plone.fieldsets==1.0rc1 plone.i18n==1.0rc1 plone.intelligenttext==1.0rc1 plone.locking==1.0rc1 plone.memoize==1.0rc1 plone.openid==1.0rc1 plone.portlets==1.0rc1 plone.session==1.0rc1 plone.theme==1.0rc1 wicked==1.1.3 five.customerize==0.1.3 five.localsitemanager==0.2 eggs-directory = /Users/optilude/.buildout/eggs executable = /opt/local/Library/Frameworks/Python.framework/Versions/2.4/bin/python http-address = 8080 location = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/instance products = %(__buildout_space_n__)s/Users/optilude/tmp/eggs/zopeskel/rc1/products /Users/optilude/tmp/eggs/zopeskel/rc1/parts/productdistros /Users/optilude/tmp/eggs/zopeskel/rc1/parts/plone recipe = plone.recipe.zope2instance scripts = user = admin:admin verbose-security = on zcml = zope2-location = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/zope2 [zopepy] _b = /Users/optilude/tmp/eggs/zopeskel/rc1/bin _d = /Users/optilude/tmp/eggs/zopeskel/rc1/develop-eggs _e = /Users/optilude/.buildout/eggs bin-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/bin develop-eggs-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/develop-eggs eggs = %(__buildout_space_n__)s%(__buildout_space_n__)sarchetypes.kss==1.2-rc1.1 kss.core==1.2-rc1.1 plone.app.content==1.0rc1 plone.app.contentmenu==1.0rc1 plone.app.contentrules==1.0rc1 plone.app.controlpanel==1.0rc1 plone.app.customerize==1.0rc1 plone.app.form==1.0rc1 plone.app.i18n==1.0rc1 plone.app.iterate==1.0rc1 plone.app.kss==1.2-rc1.1 plone.app.layout==1.0rc1 plone.app.linkintegrity==1.0rc1.1 plone.app.openid==1.0rc1 plone.app.portlets==1.0rc1 plone.app.redirector==1.0rc1 plone.app.viewletmanager==1.0rc1 plone.app.vocabularies==1.0rc1 plone.app.workflow==1.0rc1 plone.contentrules==1.0rc1 plone.fieldsets==1.0rc1 plone.i18n==1.0rc1 plone.intelligenttext==1.0rc1 plone.locking==1.0rc1 plone.memoize==1.0rc1 plone.openid==1.0rc1 plone.portlets==1.0rc1 plone.session==1.0rc1 plone.theme==1.0rc1 wicked==1.1.3 five.customerize==0.1.3 five.localsitemanager==0.2 eggs-directory = /Users/optilude/.buildout/eggs executable = /opt/local/Library/Frameworks/Python.framework/Versions/2.4/bin/python extra-paths = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/zope2/lib/python interpreter = zopepy recipe = zc.recipe.egg scripts = zopepy [plone] _b = /Users/optilude/tmp/eggs/zopeskel/rc1/bin _d = /Users/optilude/tmp/eggs/zopeskel/rc1/develop-eggs _e = /Users/optilude/.buildout/eggs bin-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/bin develop-eggs-directory = /Users/optilude/tmp/eggs/zopeskel/rc1/develop-eggs eggs = archetypes.kss==1.2-rc1.1 kss.core==1.2-rc1.1 plone.app.content==1.0rc1 plone.app.contentmenu==1.0rc1 plone.app.contentrules==1.0rc1 plone.app.controlpanel==1.0rc1 plone.app.customerize==1.0rc1 plone.app.form==1.0rc1 plone.app.i18n==1.0rc1 plone.app.iterate==1.0rc1 plone.app.kss==1.2-rc1.1 plone.app.layout==1.0rc1 plone.app.linkintegrity==1.0rc1.1 plone.app.openid==1.0rc1 plone.app.portlets==1.0rc1 plone.app.redirector==1.0rc1 plone.app.viewletmanager==1.0rc1 plone.app.vocabularies==1.0rc1 plone.app.workflow==1.0rc1 plone.contentrules==1.0rc1 plone.fieldsets==1.0rc1 plone.i18n==1.0rc1 plone.intelligenttext==1.0rc1 plone.locking==1.0rc1 plone.memoize==1.0rc1 plone.openid==1.0rc1 plone.portlets==1.0rc1 plone.session==1.0rc1 plone.theme==1.0rc1 wicked==1.1.3 five.customerize==0.1.3 five.localsitemanager==0.2 eggs-directory = /Users/optilude/.buildout/eggs executable = /opt/local/Library/Frameworks/Python.framework/Versions/2.4/bin/python find-links = http://dist.plone.org location = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/plone nested-packages = CMF-2.1.0-beta2.tar.gz prefix = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/plone products = /Users/optilude/tmp/eggs/zopeskel/rc1/parts/plone python-url = http://www.python.org/ftp/python/2.4.4/Python-2.4.4.tgz recipe = plone.recipe.plone urls = http://www.zope.org/Products/CMF/CMF-2.1.0-beta2/CMF-2.1.0-beta2.tar.gz http://plone.org/products/atcontenttypes/releases/1.2/atcontenttypes-1-2-0-… http://plone.org/products/atreferencebrowserwidget/releases/2.0/ATReference… http://plone.org/products/cmfdynamicviewfti/releases/3.0/CMFDynamicViewFTI-… http://plone.org/products/cmfformcontroller/releases/2.1/CMFFormController-… http://plone.org/products/cmfplacefulworkflow/releases/1.2.0-rc1/cmfplacefu… http://plone.googlecode.com/files/PloneBase-3.0-rc1.tar.gz http://plone.org/products/cmfquickinstallertool/releases/2.0.3/CMFQuickInst… http://plone.org/products/cmfdifftool/releases/0.3.4/cmfdifftool-0-3-4.tgz http://plone.org/products/cmftestcase/releases/0.9.6/CMFTestCase-0.9.6.tar.… http://plone.org/products/extendedpathindex/releases/2.4/ExtendedPathIndex-… http://plone.org/products/external-editor/releases/0.9.3/ExternalEditor-0.9… http://plone.org/products/groupuserfolder/releases/3.54.4/GroupUserFolder-3… http://plone.org/products/kupu/releases/1.4/kupu-1-4rc1.tgz http://plone.org/products/pts/releases/1.4.4/PlacelessTranslationService-1.… http://plone.org/products/plonetestcase/releases/0.9.6/PloneTestCase-0.9.6.… http://plone.org/products/plonetranslations/releases/3.0.3/PloneTranslation… http://plone.org/products/plonelanguagetool/releases/2.0/PloneLanguageTool-… http://plone.org/products/securemailhost/releases/1.1/SecureMailHost-1.1.ta… http://plone.org/products/resourceregistries/releases/1.4.0/resourceregistr… http://plone.org/products/statusmessages/releases/3.0/statusmessages-3.0rc1… http://plone.org/products/plonepas/releases/3.0/plonepas-3-0rc1-tar.gz http://www.zope.org/Products/PluggableAuthService/PluggableAuthService-1.5/… http://plone.org/products/passwordresettool/releases/1.0/PasswordResetTool-… http://www.zope.org/Products/PluginRegistry/PluginRegistry-1.1.2/PluginRegi… http://antiloop.plone.org/download/ZopeVersionControl-0.3.4.tar.gz http://plone.org/products/cmfeditions/releases/1.1/cmfeditions-1-1-rc1.tgz http://plone.org/products/nuplone/releases/0.8/NuPlone-0.8.tgz http://www.dieter.handshake.de/pyprojects/zope/AdvancedQuery.tgz http://plone.org/products/archetypes/releases/1.5/Archetypes-1.5.0-rc2.tar.… version-suffix-packages = PluggableAuthService-1.5.tar.gz PluginRegistry-1.1.2.tar.gz zope2-url = http://www.zope.org/Products/Zope/2.10.4/Zope-2.10.4-final.tgz Installing plone. Installing 'archetypes.kss==1.2-rc1.1', 'kss.core==1.2-rc1.1', 'plone.app.content==1.0rc1', 'plone.app.contentmenu==1.0rc1', 'plone.app.contentrules==1.0rc1', 'plone.app.controlpanel==1.0rc1', 'plone.app.customerize==1.0rc1', 'plone.app.form==1.0rc1', 'plone.app.i18n==1.0rc1', 'plone.app.iterate==1.0rc1', 'plone.app.kss==1.2-rc1.1', 'plone.app.layout==1.0rc1', 'plone.app.linkintegrity==1.0rc1.1', 'plone.app.openid==1.0rc1', 'plone.app.portlets==1.0rc1', 'plone.app.redirector==1.0rc1', 'plone.app.viewletmanager==1.0rc1', 'plone.app.vocabularies==1.0rc1', 'plone.app.workflow==1.0rc1', 'plone.contentrules==1.0rc1', 'plone.fieldsets==1.0rc1', 'plone.i18n==1.0rc1', 'plone.intelligenttext==1.0rc1', 'plone.locking==1.0rc1', 'plone.memoize==1.0rc1', 'plone.openid==1.0rc1', 'plone.portlets==1.0rc1', 'plone.session==1.0rc1', 'plone.theme==1.0rc1', 'wicked==1.1.3', 'five.customerize==0.1.3', 'five.localsitemanager==0.2'. We have the distribution that satisfies 'archetypes.kss==1.2-rc1.1'. We have the distribution that satisfies 'kss.core==1.2-rc1.1'. We have the distribution that satisfies 'plone.app.content==1.0rc1'. We have the distribution that satisfies 'plone.app.contentmenu==1.0rc1'. We have the distribution that satisfies 'plone.app.contentrules==1.0rc1'. We have the distribution that satisfies 'plone.app.controlpanel==1.0rc1'. We have the distribution that satisfies 'plone.app.customerize==1.0rc1'. We have the distribution that satisfies 'plone.app.form==1.0rc1'. We have the distribution that satisfies 'plone.app.i18n==1.0rc1'. We have the distribution that satisfies 'plone.app.iterate==1.0rc1'. We have the distribution that satisfies 'plone.app.kss==1.2-rc1.1'. We have the distribution that satisfies 'plone.app.layout==1.0rc1'. We have the distribution that satisfies 'plone.app.linkintegrity==1.0rc1.1'. We have the distribution that satisfies 'plone.app.openid==1.0rc1'. We have the distribution that satisfies 'plone.app.portlets==1.0rc1'. We have the distribution that satisfies 'plone.app.redirector==1.0rc1'. We have the distribution that satisfies 'plone.app.viewletmanager==1.0rc1'. We have the distribution that satisfies 'plone.app.vocabularies==1.0rc1'. We have the distribution that satisfies 'plone.app.workflow==1.0rc1'. We have the distribution that satisfies 'plone.contentrules==1.0rc1'. We have the distribution that satisfies 'plone.fieldsets==1.0rc1'. We have the distribution that satisfies 'plone.i18n==1.0rc1'. We have the distribution that satisfies 'plone.intelligenttext==1.0rc1'. We have the distribution that satisfies 'plone.locking==1.0rc1'. We have the distribution that satisfies 'plone.memoize==1.0rc1'. We have the distribution that satisfies 'plone.openid==1.0rc1'. We have the distribution that satisfies 'plone.portlets==1.0rc1'. We have the distribution that satisfies 'plone.session==1.0rc1'. We have the distribution that satisfies 'plone.theme==1.0rc1'. We have the distribution that satisfies 'wicked==1.1.3'. We have the distribution that satisfies 'five.customerize==0.1.3'. We have the distribution that satisfies 'five.localsitemanager==0.2'. Getting required 'setuptools' required by five.customerize 0.1.3. required by five.localsitemanager 0.2. required by plone.app.content 1.0rc1. required by plone.app.contentmenu 1.0rc1. required by plone.app.contentrules 1.0rc1. required by plone.app.controlpanel 1.0rc1. required by plone.app.customerize 1.0rc1. required by plone.app.form 1.0rc1. required by plone.app.i18n 1.0rc1. required by plone.app.iterate 1.0rc1. required by plone.app.layout 1.0rc1. required by plone.app.openid 1.0rc1. required by plone.app.portlets 1.0rc1. required by plone.app.redirector 1.0rc1. required by plone.app.viewletmanager 1.0rc1. required by plone.app.vocabularies 1.0rc1. required by plone.app.workflow 1.0rc1. required by plone.contentrules 1.0rc1. required by plone.fieldsets 1.0rc1. required by plone.i18n 1.0rc1. required by plone.intelligenttext 1.0rc1. required by plone.locking 1.0rc1. required by plone.memoize 1.0rc1. required by plone.openid 1.0rc1. required by plone.portlets 1.0rc1. required by plone.session 1.0rc1. required by plone.theme 1.0rc1. required by plone.app.linkintegrity 1.0rc1.1. required by wicked 1.1.3. required by archetypes.kss 1.2-rc1.1. required by kss.core 1.2-rc1.1. required by plone.app.kss 1.2-rc1.1. Download error: (61, 'Connection refused') -- Some packages may not be found! We have the best distribution that satisfies 'setuptools'. Picked: setuptools = 0.6c6 Getting required 'python-openid>=2.0.0,<2.0.999' required by plone.openid 1.0rc1. We have the best distribution that satisfies 'python-openid>=2.0.0,<2.0.999'. Picked: python-openid = 2.0.1 While: Installing plone. An internal error occured due to a bug in either zc.buildout or in a recipe being used: URLError: <urlopen error (61, 'Connection refused')> -- Acquisition is a jealous mistress

1 0

Cygwin build of PIL 1.1.6 hangs
by Steve Holden July 14, 2007

July 14, 2007

Has anyone noticed or reported Cygwin problems? The ordinarily well-behaved PIL install hangs on Cygwin. I put debug prints inside spawn.py and it appears that the os.waitpid(pid, 0) inside spawn_posix is failing to return when the gcc task completes. Nothing on Google about this that I can find, and no response from either the PIL or Cygwin lists. This seems a pretty fundamental breakage to not get noticed. What have I done wrong? This is using Python 2.5.2 (same thing happens with 2.5.1) on Cygwin 1.5.24, using gcc 3.4.4-3. The task manager shows 100% CPU (with kernel usage hovering about 35%) and a python.exe process gobbling CPU like there's no tomorrow. If I CTRL/C the build I get an "interrupted" diagnostic but the python.exe (presumably the child) continues to gobble CPU until killed from the task manager. I haven't yet started debugging the child process, as I am hoping someone knows of a fix. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --------------- Asciimercial ------------------ Get on the web: Blog, lens and tag the Internet Many services currently offer free registration ----------- Thank You for Reading -------------

1 0

In using bdist_rpm, how do I get documentation files to go where they belong?
by Stanley A. Klein July 13, 2007

July 13, 2007

Now that I understand how to prepare the setup.cfg for Fedora, I have been able to generate some rpms for Python packages using bdist_rpm. However, using only find_packages() causes only the executable part to be packaged. I have made various attempts to get the documentation packaged without success. 1. The first issue is that I get a peculiar error that may be an incorrect setup.py/setup.cfg or may be a bug. The result of the attempt is an error in copying a file called "d" that I didn't declare and doesn't exist. I did declare a directory called "docs". 2. The second issue is that Fedora wants to put documentation files in /usr/share/doc/package_name_and_version and I can't figure out how to make that happen. This placement of documentation is specified under the Unix Filesystem Hierarchy Standard referenced under the Linux Standards Base. The same standard specifies configuration files going under /etc, and the same issue applies if there are any such files. Below is an example from an attempt to package MojoView (from the Python Cheeseshop) with a modified setup.py. I would appreciate any help. Thanks. Stan Klein ------------------------- MojoView packaging attempt ----------------- My setup.py is: from setuptools import setup, find_packages setup(name="MojoView", version="1.0", description="Simple framwork for building PyGTK database applications", author="Jamey Cribbs", author_email="jcribbs(a)twmi.rr.com", url="http://www.netpromi.com/mojoview.html", packages = find_packages(), data_files = [("docs", "docs/*"), ("examples", "examples/*"), ("gtk", "gtk/*"), ("readme.txt", "readme.txt")] ) The setup.cfg is: #setup.cfg to get proper rpms [install] optimize = 1 [bdist_rpm] doc_files = readme.txt docs/ gtk/ examples/ The output from the attempt is: [stan@localhost MojoView-1.0]$ python setup.py bdist_rpm running bdist_rpm running egg_info writing MojoView.egg-info/PKG-INFO writing top-level names to MojoView.egg-info/top_level.txt writing dependency_links to MojoView.egg-info/dependency_links.txt reading manifest file 'MojoView.egg-info/SOURCES.txt' writing manifest file 'MojoView.egg-info/SOURCES.txt' writing 'build/bdist.linux-i686/rpm/SPECS/MojoView.spec' running sdist warning: sdist: standard file not found: should have one of README, README.txt creating MojoView-1.0 creating MojoView-1.0/MojoView.egg-info creating MojoView-1.0/mojoview making hard links in MojoView-1.0... hard linking setup.cfg -> MojoView-1.0 hard linking setup.py -> MojoView-1.0 hard linking MojoView.egg-info/PKG-INFO -> MojoView-1.0/MojoView.egg-info hard linking MojoView.egg-info/SOURCES.txt -> MojoView-1.0/MojoView.egg-info hard linking MojoView.egg-info/dependency_links.txt -> MojoView-1.0/MojoView.egg-info hard linking MojoView.egg-info/top_level.txt -> MojoView-1.0/MojoView.egg-info hard linking mojoview/__init__.py -> MojoView-1.0/mojoview hard linking mojoview/aboutwin.py -> MojoView-1.0/mojoview hard linking mojoview/browse.py -> MojoView-1.0/mojoview hard linking mojoview/busycursor.py -> MojoView-1.0/mojoview hard linking mojoview/clist.py -> MojoView-1.0/mojoview hard linking mojoview/editdaterange.py -> MojoView-1.0/mojoview hard linking mojoview/editrec.py -> MojoView-1.0/mojoview hard linking mojoview/editwin.py -> MojoView-1.0/mojoview hard linking mojoview/errorwin.py -> MojoView-1.0/mojoview hard linking mojoview/guierror.py -> MojoView-1.0/mojoview hard linking mojoview/mainmenu.py -> MojoView-1.0/mojoview hard linking mojoview/mv.py -> MojoView-1.0/mojoview hard linking mojoview/notebookwin.py -> MojoView-1.0/mojoview hard linking mojoview/toolbar.py -> MojoView-1.0/mojoview copying setup.cfg -> MojoView-1.0 Writing MojoView-1.0/setup.cfg tar -cf dist/MojoView-1.0.tar MojoView-1.0 gzip -f9 dist/MojoView-1.0.tar removing 'MojoView-1.0' (and everything under it) copying dist/MojoView-1.0.tar.gz -> build/bdist.linux-i686/rpm/SOURCES building RPMs rpmbuild -ba --define _topdir /home/stan/exper/mojoview/MojoView-1.0/build/bdist.linux-i686/rpm --clean build/bdist.linux-i686/rpm/SPECS/MojoView.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.61946 + umask 022 + cd /home/stan/exper/mojoview/MojoView-1.0/build/bdist.linux-i686/rpm/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/stan/exper/mojoview/MojoView-1.0/build/bdist.linux-i686/rpm/BUILD + rm -rf MojoView-1.0 + /bin/gzip -dc /home/stan/exper/mojoview/MojoView-1.0/build/bdist.linux-i686/rpm/SOURCES/MojoView-1.0.tar.gz + tar -xvvf - drwxrwxr-x stan/stan 0 2007-07-13 14:37 MojoView-1.0/ drwxrwxr-x stan/stan 0 2007-07-13 14:37 MojoView-1.0/MojoView.egg-info/ -rw-rw-r-- stan/stan 9 2007-07-13 14:37 MojoView-1.0/MojoView.egg-info/top_level.txt -rw-rw-r-- stan/stan 437 2007-07-13 14:37 MojoView-1.0/MojoView.egg-info/SOURCES.txt -rw-rw-r-- stan/stan 276 2007-07-13 14:37 MojoView-1.0/MojoView.egg-info/PKG-INFO -rw-rw-r-- stan/stan 1 2007-07-13 14:37 MojoView-1.0/MojoView.egg-info/dependency_links.txt -rw-rw-rw- stan/stan 519 2007-07-12 17:00 MojoView-1.0/setup.py drwxrwxr-x stan/stan 0 2007-07-13 14:37 MojoView-1.0/mojoview/ -rw-rw-rw- stan/stan 2034 2003-08-21 14:17 MojoView-1.0/mojoview/editdaterange.py -rw-rw-rw- stan/stan 23415 2003-09-02 16:51 MojoView-1.0/mojoview/browse.py -rw-rw-rw- stan/stan 2212 2003-09-02 16:38 MojoView-1.0/mojoview/notebookwin.py -rw-rw-rw- stan/stan 1477 2003-08-08 15:41 MojoView-1.0/mojoview/editwin.py-rw-rw-rw- stan/stan 593 2003-08-08 15:41 MojoView-1.0/mojoview/busycursor.py -rw-rw-rw- stan/stan 1829 2003-09-02 16:29 MojoView-1.0/mojoview/toolbar.py-rw-rw-rw- stan/stan 16470 2003-09-02 16:50 MojoView-1.0/mojoview/clist.py -rw-rw-rw- stan/stan 373 2003-08-08 15:42 MojoView-1.0/mojoview/errorwin.py -rw-rw-rw- stan/stan 26 2003-08-08 15:39 MojoView-1.0/mojoview/__init__.py -rw-rw-rw- stan/stan 520 2003-08-12 08:56 MojoView-1.0/mojoview/aboutwin.py -rw-rw-rw- stan/stan 3675 2003-09-02 16:39 MojoView-1.0/mojoview/mainmenu.py -rw-rw-rw- stan/stan 317 2003-08-28 14:31 MojoView-1.0/mojoview/mv.py -rw-rw-rw- stan/stan 1983 2003-09-03 13:18 MojoView-1.0/mojoview/guierror.py -rw-rw-rw- stan/stan 2849 2003-09-02 16:27 MojoView-1.0/mojoview/editrec.py-rw-rw-r-- stan/stan 143 2007-07-13 14:37 MojoView-1.0/setup.cfg -rw-rw-r-- stan/stan 276 2007-07-13 14:37 MojoView-1.0/PKG-INFO + STATUS=0 + '[' 0 -ne 0 ']' + cd MojoView-1.0 ++ /usr/bin/id -u + '[' 500 = 0 ']' ++ /usr/bin/id -u + '[' 500 = 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.61946 + umask 022 + cd /home/stan/exper/mojoview/MojoView-1.0/build/bdist.linux-i686/rpm/BUILD + cd MojoView-1.0 + LANG=C + export LANG + unset DISPLAY + python setup.py build running build running build_py creating build creating build/lib creating build/lib/mojoview copying mojoview/editdaterange.py -> build/lib/mojoview copying mojoview/browse.py -> build/lib/mojoview copying mojoview/notebookwin.py -> build/lib/mojoview copying mojoview/editwin.py -> build/lib/mojoview copying mojoview/busycursor.py -> build/lib/mojoview copying mojoview/toolbar.py -> build/lib/mojoview copying mojoview/clist.py -> build/lib/mojoview copying mojoview/errorwin.py -> build/lib/mojoview copying mojoview/__init__.py -> build/lib/mojoview copying mojoview/aboutwin.py -> build/lib/mojoview copying mojoview/mainmenu.py -> build/lib/mojoview copying mojoview/mv.py -> build/lib/mojoview copying mojoview/guierror.py -> build/lib/mojoview copying mojoview/editrec.py -> build/lib/mojoview + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.75576 + umask 022 + cd /home/stan/exper/mojoview/MojoView-1.0/build/bdist.linux-i686/rpm/BUILD + cd MojoView-1.0 + LANG=C + export LANG + unset DISPLAY + python setup.py install --single-version-externally-managed --root=/var/tmp/MojoView-1.0-1-buildroot --record=INSTALLED_FILES running install running build running build_py running install_lib writing byte-compilation script '/tmp/tmp0s5onf.py' /usr/bin/python -O /tmp/tmp0s5onf.py removing /tmp/tmp0s5onf.py running install_data error: can't copy 'd': doesn't exist or not a regular file error: Bad exit status from /var/tmp/rpm-tmp.75576 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.75576 (%install) error: command 'rpmbuild' failed with exit status 1

1 0

Case sensitivity of package names
by Jim Fulton July 12, 2007

July 12, 2007

On Jul 12, 2007, at 2:43 PM, Phillip J. Eby wrote: > At 02:15 PM 7/12/2007 -0400, Jim Fulton wrote: >> I want to make sure I understand this. I would hope that searching >> would be case insensitive and otherwise flexible wrt names. > > PyPI's searching is indeed case insensitive, and is a substring/ > keyword search as well. > > >> Is there >> any reason we can't expect URLs and requirement specifications to be >> precisely spelled? That is, if someone names their package "sPaM", I >> see no reason why PyPI needs to support anything other than >> http:// www.python.org/pypi/sPaM as the one URL of the package. >> Someone >> should be able to use the search UI to search for "spam" and see a >> result that includes "sPaM". From then on, they should be able to >> type the name "sPaM". Or am I missing something? > > You're missing that the subject is about similarity of names. > A typo of say, 'SPam' shouldn't return me some package *other* > than the one I'm looking for. I No, I understand that part. I understand the desire to avoid conflicts that cause problems down the road. I would prefer to "disallow" this by rejecting new package names that are too similar to already-registered packages. > t'd be nice if the resulting page said something besides "Not > Found", too... like "there's no SPam, but here are a bunch of > packages whose name contains 'spam'". I think this would be fine in a human interface. > If it did that, setuptools would be able to find the right page > without hitting the main index, too. But redirection, as proposed > by Martin, also accomplishes the same thing. I really don't like this for setuptools. My preference is that setuptools should be required to ask for a package with precise spelling. > And again, all this helps human direct users of the index, too. I think it encourages humans to do bad things. Is someone misspells ZODB3 as zodb3 and is able to install it with easy_install, then they'll be tempted to use the name "zodb3" in their requirements specifications. That is a bad thing IMO. We're talking about technical users and I think it is reasonable to expect them to be precise in their specifications. I could live with case-insensitive package names if we (for some definition of we, possibly being Guido) decided we want them, but I'd prefer they be case sensitive. I'd still be in favor of avoiding confusing duplicates. If we stick with case-sentitive package names, then I'd prefer that the interaction of setuptools with the index be case sensitive. I wouldn't object to setuptools giving people help. So, for example, if I type "zodb3", I wouldn't object to setuptools letting the user know that maybe they should use ZODB3. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 4

Re: [Distutils] [Catalog-sig] start on static generation, and caching - apache config.
by Jim Fulton July 11, 2007

July 11, 2007

On Jul 11, 2007, at 6:11 PM, Richard Jones wrote: > On Thu, 12 Jul 2007, Martin v. Löwis wrote: >>> The questions for us is, how much effort we are willing to make to >>> prevent people from shooting themselves in the foot. I can >>> understand >>> why Phillip would like the package index to prevent people from >>> choosing >>> problematic package names. >> >> That's not my understanding - the issue isn't with "problematic >> package >> names", but with conflicting package names. IOW, any single name is >> fine - it's a pair of names that would cause a problem (and only if >> you wanted to install both packages on the same system). > > A big issue that's not been raised is that *distutils* have no > package name > rules, but it's being proposed that PyPI does - thus a package > author will > potentially get an error when uploading their package, and also the > name that > appears in the index may be quite different to the name of their > package. Maybe distutils should have more package name rules than it does now. We (the Community) should be free to change things based on experience. We now have a lot more experience with this stuff than we had a few years ago. Maybe we should consider a reset. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

Re: [Distutils] Why so many zc.buildout versions?
by Jim Fulton July 11, 2007

July 11, 2007

You raise a really good point, which is especially relevant in light of pypi performance issues and discussions. I'm copying the distutils and catalog sigs to get some wider discussion. I apologize for the cross posting. I'm beginning to wonder about the strategy that setuptools uses, or maybe about the way we are using the index. It's important to note that there is nothing specific about the buildout package here. It is very important to make multiple versions available to support requirements for specific package versions. It make builds/installs repeatable, whether talking about buildout or other systems built on setuptools. When someone has tested and wants to release an application built from a collection of distributions, they will want to specify those *specific* versions for future builds or installs. This means that we need to retain any versions published indefinitely in a way that can be found by setuptools. Currently, the only way to support multiple versions with the cheeseshop is to unhide past releases. This has a fairly severe effect on performance. As the example below shows, setuptools will fetch the package page and then fetch the pages for each release. That's a lot of requests. What makes it worse is that the individual package pages can be fairly long. I've gotten in the habit of including full documentation on every release page. For example, recent release pages for zc.buildout are around 200K. This is a fairly significant amount of data to transfer. This will certainly make the scanning process take a long time for clients. (Obviously, if we keep doing things the way we are, I'll need to stop doing that.) All of this aggravates any performance problems we might have. Up to now, setuptools has tried hard to use existing systems without change. This means that it reuses systems designed primarily for people, not software. I think that setuptools rightly took the approach it has up to now so that progress could be made without making people change other systems. This was appropriate when setuptools was evolving and people were figuring out ways to use it. I think it is time to take a step back and think a lot harder about how we'd want to structure an index to support setuptools. IMO, a setuptools-aware index would have a single page for each package: - The single page would be published in a case-insensitive way. It would be nice to find a way to avoid this, or maybe we should use a windows-based web server. :) It would also be served very cheaply, for example statically. - The single page would list links for all available distributions, which should include all distributions published. It would also list any other URLs that should be scanned for releases, when releases aren't all uploaded to PyPI. - The single page would contain very little additional information. It would be for use by software, not humans. In addition, the root page with a trailing / would be empty and very cheap. There are a lot of ways we could achieve this pretty cheaply while keeping the existing system pretty much as it is. For example, the current effort to bake static pages could bake these pages instead. We could make the new index available at a different URL for people to play with while we worked the kinks out of the process. Of course, those of us who use the cheesehop and setuptools extensively can also achieve much of this by changing the way we work. Thoughts? Jim On Jul 10, 2007, at 8:44 AM, Philipp von Weitershausen wrote: > When easy_installing zc.buildout I realized that the CheeseShop > still lists a gazillion old versions of zc.buildout. That makes it > take quite some time to install zc.buildout (see below), and I > reckon the same sort of check has to happen each time it looks for > a new version of that egg... > > Is there any reason for having so many old versions around? > > > $ easy_install zc.buildout > Searching for zc.buildout > Reading http://cheeseshop.python.org/pypi/zc.buildout/ > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b19 > Reading http://svn.zope.org/zc.buildout > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b22 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b23 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b20 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b21 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b26 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b27 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b24 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b25 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b28 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b17 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b16 > Reading http://cheeseshop.python.org/pypi/zc.buildout/1.0.0b18 > Best match: zc.buildout 1.0.0b28 > ... -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

4 9

Merge catalog and distutils sigs
by Jim Fulton July 10, 2007

July 10, 2007

Is there are good reason for the distutils and catalog sigs to be separate? Now, that PyPI is an integral part of the distribution system, I find most topics are really of of interested to both sigs, and I bet that the overlap between the sigs is significant. Would anyone object to combining them? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

Buildout not updating setuptools
by Graham Stratton July 9, 2007

July 9, 2007

Hi, I'm having a problem with buildout. My system has setuptools 0.6c5 installed. The buildout bootstrap.py script doesn't install the latest version, and nor does running bin/buildout. The result is that the Routes install fails with The required version of setuptools (>=0.6c6) is not available, ... The problem seems to be that bootstrap.py creates a link for setuptools in develop-eggs. Why would that be? Thanks, Graham

4 11

Re: [Distutils] [Web-SIG] entry points, etc
by Ian Bicking July 7, 2007

July 7, 2007

Jim Fulton wrote: > > On Jul 6, 2007, at 11:55 PM, Ian Bicking wrote: > >> Incidentally, something that would be nice with wsgiconfig is if we >> could all agree on how to specify things like entry points and objects. >> Specifically Paste Deploy uses egg:Distribution#ep_name, and >> zc.buildout uses Distribution:ep_name. And Paste Deploy defaults to >> ep_name=main while zc.buildout defaults to ep_name=default. > > Yup. > > Some notes. # is unattractive to me because it looks like a comment. > ConfigParser is a bit odd in it's treatment of #s. It treates them as > comments after empty lines and after section names, but not after comments. If ConfigParser did pay attention to comments it would make everything much more complicated. But that's another issue. > I used ":" because setuptools uses module:name when defining entry > points. That may not have been a good reason. Well, it could be good or bad overlap. Mostly it has to be something illegal in a distribution name, and ideally in any specifier (so you can do Package==0.5:ep_name). > If we agree on some standard, I'll support it. That should happen over > on the distutils-sig list. OK, copied over. >> Paste Deploy uses "entry_point_type = object.name" when you aren't using >> an entry point, but I'd like to switch to just "object.name" with an >> optional "object.name [ep_type]". This helps out those people who have >> some hangup with writing their own setup.py. So having a clear way to >> distinguish between an object reference and an entry point reference >> would be ideal. I still would prefer the entry points, as they make it >> easier to search the system for providing objects and easier to handle >> backward compatibility, but I don't have any reason to *require* entry >> points in my code generally. > > It is hard to assess this out of context. I will note that setuptools > uses dotted_module_name:dotted_object_name to name objects and I'd be > inclined to be consistent with that. If we used a different delimiter > between eggs and entry points and between modules and names, then we'd > be able to tell the refrecnes apart. Again, I think this is more > general than web applications. Another case came up as I was thinking about this, which is referring to an object in a specific Python file (not module). I find this very useful when I'm doing some kind of configuration that involves deployment-specific code. I really don't want to create a package and module and fiddle with sys.path, for a bit of code that is purely deployment specific. So I'd like to also allow for a specifier like filename:object_name. We could use prefixes for all of these. I'm fine supporting : instead of # for entry point names. We could use prefixes, e.g., "egg:Package:ep". Somehow that reads a little funny to me, too many colons. We could also just use "egg Package:ep", which maybe reads better. Then there'd also be "python module:object", and "file filename.py:object". Maybe "python " would be the default, I'm not sure. I encourage people to use entry points, but I don't mind including "egg " -- if anything, I think the name is helpful to people who aren't always clear on the distinction between distributions and packages and modules. The default entry point name is also important. I prefer "main" because I think it better describes the purpose of the entry-point-that-need-not-be-named. "default" feels like it's just describing the mechanism of the entry point loader. -- Ian Bicking : ianb(a)colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers

2 1

Preferring final releases
by Jim Fulton July 7, 2007

July 7, 2007

Currently, when looking for a new release, easy_install and buildout look for the newest distributions that satisfy a requirement. They will, for example, prefer a newer development release or preliminary release (dev, alpha, beta, or rc) over a final release. I don't think this is a good default policy. In buildout, I'm going to add an option, prefer-final, to control this. If this option is true, then buildout will prefer final distributions over non-final distributions. It will choose the latest final version that meets a requirement if there is one. Maybe buildout should make this the default. (Thoughts?) In any case, since buildout lets people create their own defaults for buildout options, people will be able to choose any default they wish. With this option enabled, you'll be able to get a non-final distribution by explicitly requiring it. I think easy_install and setuptools should provide a similar option and provide a way (presumably through setup.cfg) to make it the default. For backward compatibility reasons, it may not be possible to make this the default policy for setuptools, although, arguably, it is a better default. Jim Note that for buildout, what I said above isn't accurate. :) Buildout prefers develop distributions over non-develop distributions. It will currently choose a develop distribution that meets a requirement, if there is one. If prefer-final is enabled, then buildout will choose the latest develop distribution that satisfies the requirement, if there is one, otherwise, it will pick the latest final distribution that meets a requirement, if there is one, otherwise, it will pick the latest distribution that meets a requirement. -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 2

Setuptools feature request: simplified version specification
by Jim Fulton July 6, 2007

July 6, 2007

We (me and a bunch of my Zope friends) find that we'll often want version specifications of the form: project_name >=Vdev, <V+1dev (e.g. "foo >=1dev, <2dev") We think this is so common that we'd like a short-hand way of spelling it. I'll note that I'm not even sure I got the spelling above right. The intent is to request version 1, meaning any release of version 1. I think that's what I spelled above, although I'm not sure. If I got it wrong, maybe someone will correct me. Aside from the verbosity of the spelling above, I think the difficulty in spelling it is a strike against it. Note that a naive spelling: "foo >=1, <2" is wrong because it excludes pre-releases of 1 and includes pre-releases of 2. I propose that a valid version that ends in a number and that isn't preceded by an operator be a valid version specifier and be interpreted as a range. So, assuming that I know how to spell the range, a specification of: project_name V (e.g. "foo 1") would be equivalent to: project_name >=Vdev, <V+1 (e.g. "foo >=1dev, <2dev") This would work with multi-part versions, so "foo 1.2" would be equivalent to "foo >=1.2dev <1.3dev". Note that this could be combined with other version specifiers. For example, to require any version 1 or 2 of foo or versions 3.2 final or later: foo 1, 2, >=3.2 Also note that any version will do, so: foo 1.2a1 would be equivalent to: foo >=1.2a1dev <1.2a2dev And note that versions that don't end in numbers wouldn't be valid version specifiers, so: foo 1a would not be a valid specifier. Thoughts? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

5 7

setuptools: Problem with auto-scripts and standalone scripts
by Frank McIngvale July 5, 2007

July 5, 2007

Hi, I'm trying to use setuptools auto-script feature with standalone scripts and am having problems. Say I have a script "mypkg/scripts/foo.py": --------------------- import sys print "Hello foo! My args are:",sys.argv --------------------- When I try wrapping it like this: 'console_scripts': [ 'foo = mypkg.scripts.foo', ] Then run like this: $ foo aa bb cc It appears to start OK (and it gets the cmdline args) but crashes with a traceback: ------------ Hello foo! My args are: ['c:\\frank\\py25\\Scripts\\foo-script.py', 'aa', 'bb', 'cc'] Traceback (most recent call last): File "c:\frank\py25\Scripts\foo-script.py", line 8, in <module> load_entry_point('mypkg==0.99.50-rc1', 'console_scripts', 'foo')() TypeError: 'module' object is not callable ------------ Am I setting up 'console_scripts' incorrectly, or is this kind of usage not supported? thanks, Frank

2 2

disable register and upload commands for a setup.py
by Jeff Kowalczyk July 4, 2007

July 4, 2007

What would be the most reliable way to disable, with error output, the PyPI 'register' and/or 'upload' commands for a given setup.py? This is for developing certain python egg/packages having setup.py:setup() including full package metadata, but which should never (or not yet) accidentally be registered with PyPI. Thanks.

2 1

Looking for a presentation on Egg
by Andreas Jung July 4, 2007

July 4, 2007

Hi, I have to give a 30 minute presentation on Python egg at our next company developer meeting. Does anyone know of a presentation or slides on this topic to be used as a basis? Thanks, Andreas

3 3

Re: [Distutils] [PEAK] Dependencies before calling setup()
by Phillip J. Eby July 4, 2007

July 4, 2007

At 06:16 PM 7/3/2007 +0400, Timur Izhbulatov wrote: >Hi all, > >I use Cheetah in my project and want to precompile templates in my >project's setup.py. So, I need to have Cheetah installed *before* >setup() is called. Don't do that. setup scripts must *never* perform such actions before setup() is called. What if someone is just running "setup.py --help", after all? NEVER do this. easy_install's sandboxing code will also reject your package as unsafe to run if you attempt something like this. >I'm trying to use setuptools.command.easy_install.main(['Cheetah']) >but I can't find any way to update sys.path after that. Is there any >'official' way to do this? The official way to require that a package is available during setup() execution is viat the 'setup_requires' keyword, similar to the 'install_requires' keyword. If you need the same package in both situations, you must list it in both keywords. To actually do the precompile, you should subclass the install_data or install_lib command, and override its run() method to do the compilation, as well as doing whatever it did before. You use the 'cmdclass' keyword to setup() to pass in a dictionary mapping command names to your subclass(es). Your subclasses *must* honor the options they are given, and not attempt to install anything except where they are told. The options will be available as attributes of the instance created by the distutils. (Oh, and speaking of the distutils, the correct place for discussion/support of setuptools is the distutils-SIG. Please direct future correspondence there. Thanks.)

2 1

setuptools --no-dependencies option needed?
by Rob Cakebread July 3, 2007

July 3, 2007

Hello, I'm wondering if a --no-dependencies option would be useful. In Gentoo we edit every setup.py file that has install_requires, setup_requires, or extra_requires and remove that with sed or a patch because our package manager takes care of installing all dependencies and because users may already have packages installed previously without setuptools (in python 2.4). We've found that can cause problems[1] and are considering using --single-version-externally-managed, but ideally we'd like to use the full features of setuptools (without losing the ability to install multiple versions, require-ing specific versions etc.). Would an option similar to --single-version-externally-managed that simply doesn't check for installed dependencies and does not try to download and install any dependencies be possible? Rob [1] http://bugs.gentoo.org/show_bug.cgi?id=183977

2 5

Missing options for setuptools develop
by Jamie Kirkpatrick July 2, 2007

July 2, 2007

Couple of things. Currently there is no way to pass custom options through setuptools "develop" to distutils build_ext. What this means in practice is that you cannot do the following things: • pass the --debug flag to build_ext so as to have your module build against debug libraries. • pass any of the SWIG options through. • I'm sure there are other limitations. Because of this I ended up abandoning the swig functionality of distutils and running that as a pre distuils phase of my build scripts - it would be better If I could use it through distutils though. The show stopper is the fact I can't build against debug libraries - this means I cannot mix the --debug type builds and the develop functionality, something that seems like a logical thing to do. Is there any chance that someone could find a way to allow options to be passed through to build_ext as it is run? I'm sure its just a case of adding another option to setuptools develop and then passing it through at the relevant point. If noone wants to take it on I'm happy to write a patch if we all agree its the way to go. Thanks in advance Jamie

3 3

Performance implications of having large numbers of eggs?
by Dave Peterson July 2, 2007

July 2, 2007

Has anyone done any investigation into the performance implications of having large numbers of eggs installed? Is there any sort of performance hit? It seems to me that having a really large path might slow down imports a bit, though I suspect this is in C code so probably not a significant problem. It also seems like there might be some startup penalties due to the overhead of setting up the path when using eggs, but this is a one-time cost during python startup, so probably not too bad either. I'm asking because we're in the process to switching our open-source Enthought Tool Suite library to a distribution of components via eggs and we're having some internal debate as to whether we need to minimize the number of eggs or not. It definitely seems nice to have smaller subsets of functionality -- from the point of being able to make things stable, managing their APIs, managing cross-component dependencies, and from the user update size viewpoint. But are we paying a performance penalty for going too small in scope with our eggs? -- Dave

4 4

Re: [Distutils] setup.py develop for extras?
by Phillip J. Eby July 1, 2007

July 1, 2007

At 12:07 AM 7/2/2007 -0400, Jorge Vargas wrote: >Hi how could I trigger installing extras with develop? > >for example > >easy_install somePackage >equals >cd somePackage >python setup.py develop > >easy_install somePackage[someExtras] >equals??? You just said it. First put the package in develop mode, then run easy_install somePackage[extras].

1 0

setup.py develop for extras?
by Jorge Vargas July 1, 2007

July 1, 2007

Hi how could I trigger installing extras with develop? for example easy_install somePackage equals cd somePackage python setup.py develop easy_install somePackage[someExtras] equals???

1 0