From kyosohma at gmail.com Sun Dec 2 22:40:09 2007 From: kyosohma at gmail.com (Mike Driscoll) Date: Sun, 2 Dec 2007 15:40:09 -0600 Subject: [Distutils] easy-install question Message-ID: I was told the other day that if I ran the easy-setup.py file on the PEAK website, it would basically download a broken version of distutils since the current version is automatically included with Python. This proved to be correct at my distutils commands quit functioning altogether when I did that. So I was wondering if there is some way that easy-install or the distutils package could be set up to detect if there's a version already installed? This would allow the program to stop if the local copy is newer than the one being installed...or it could just warn the user that they are trying to install an older version and give them the option to abort or continue. It would have saved me quite a few headaches if this had been the case. Thank you for your thoughts! Mike Driscoll From pje at telecommunity.com Mon Dec 3 03:38:54 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 02 Dec 2007 21:38:54 -0500 Subject: [Distutils] easy-install question In-Reply-To: References: Message-ID: <20071203023851.C68D83A40A5@sparrow.telecommunity.com> At 03:40 PM 12/2/2007 -0600, Mike Driscoll wrote: >I was told the other day that if I ran the easy-setup.py file on the >PEAK website, it would basically download a broken version of >distutils since the current version is automatically included with >Python. This proved to be correct at my distutils commands quit >functioning altogether when I did that. I believe you are confused. First, it's ez_setup.py, not easy-setup.py. Second, it doesn't install distutils, broken or otherwise. >So I was wondering if there is some way that easy-install or the >distutils package could be set up to detect if there's a version >already installed? As far as I'm aware, this is the only place you can install the distutils from: http://www.python.org/community/sigs/current/distutils-sig/download/ And that page warns that if you're using Python 1.6 or later, you don't need to download the distutils at all. > This would allow the program to stop if the local >copy is newer than the one being installed...or it could just warn the >user that they are trying to install an older version and give them >the option to abort or continue. In order to stop the old distutils from wiping out new distutils, it would be necessary to modify the old distutils... i.e., make them not the old distutils any more. As far as I'm aware, there is nobody available to do this. From beau.butler at gmail.com Mon Dec 3 04:26:10 2007 From: beau.butler at gmail.com (Beau Butler) Date: Mon, 3 Dec 2007 16:26:10 +1300 Subject: [Distutils] Download-only then build/install on no-net sandbox? Message-ID: Hi People I'm hoping someone can answer what I think is a quite simple question, In short:, how do I tell easy_install i just want it to download an egg, then compile/install it later? I know how to download/compile, then install later, but not the other way around? A little background: My use case is i am doing up-to-date python (2.5) & TG (1.0.3.2) stuff on a bunch of old platforms (RHEL4, etc that have py2.3 at best), that are locked down and don't have net access of their own, just SSH in. I currently make a virtual-python-like sandbox environment with a simple makefile that does, roughly: On my dev machine: * Gets Python, builds it * Gets setuptools, python-setup.py-installs it * Does easy_install -zmaxd . TurboGears etc. * Packs all that into a single .tgz along with the makefile itself. I then scp the tgz to the locked-down target box, untar it and run the makefile again which: * Builds Python and setuptools * Does easy_install -f . TurboGears etc. All this works quite nicely until i want to do things like have psycopg2. Basically doing things the "zmaxd way" causes the download and compile steps to occur on my dev machine, and the install on the target machine, which then fails due to different Postgres libraries. So my question is - is there an easy way to tell easy_install to just download the source egg but not build it? So that I can then build it on the target machine...? (BTW: slightly ironically the PEAK page http://peak.telecommunity.com/DevCenter/EasyInstall has this as a FAQ - "If you have another machine of the same operating system and library versions (or if the packages aren't platform-specific), you can create the directory of eggs using a command like this" describing the zmaxd method, but sadly it says nothing about what to do about *different* OS versions...) Many thanks in advance! Beau Butler Python And Linux Dude Auckland, New Zealand I have created a simple makefile for myself which does a two-step - it makes a python2.5-with-setuptools sandbox on my dev machine From cz at gocept.com Mon Dec 3 08:02:51 2007 From: cz at gocept.com (Christian Zagrodnick) Date: Mon, 3 Dec 2007 08:02:51 +0100 Subject: [Distutils] zc.buildout: Build python in buildout References: <1166F969-3B48-4352-84F8-58F4DCA66AE6@zope.com> Message-ID: On 2007-11-30 16:41:05 +0100, "Ignas Mikalajunas" said: >>> I suspect that a better solution would be to find a way to bootstrap >>> the buildout in a way that included building Python as part of the >>> bootstrapping process. >> >> That would certainly the best approach. Only that I have no idea how to >> do that. :( > > > Examples: > > http://source.schooltool.org/viewcvs/trunk/st-buildout/?rev=7260#dirlist > - uses a shell script that builds python using buildout, and then > builds the product using the new python > > http://source.schooltool.org/viewcvs/trunk/st-buildout/ - uses a > patched bootstrap.py that builds virtual python and uses the virtual > python to bootstrap buildout > > hope that helps Yes, thanks for the pointers. -- Christian Zagrodnick gocept gmbh & co. kg ? forsterstrasse 29 ? 06112 halle/saale www.gocept.com ? fon. +49 345 12298894 ? fax. +49 345 12298891 From pje at telecommunity.com Mon Dec 3 15:25:15 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 03 Dec 2007 09:25:15 -0500 Subject: [Distutils] Download-only then build/install on no-net sandbox? In-Reply-To: References: Message-ID: <20071203142530.559393A40FF@sparrow.telecommunity.com> At 04:26 PM 12/3/2007 +1300, Beau Butler wrote: >Hi People I'm hoping someone can answer what I think is a quite simple >question, > >In short:, how do I tell easy_install i just want it to download an >egg, then compile/install it later? I know how to download/compile, >then install later, but not the other way around? Use the -e (--editable) option. Specifically, use "-eb somedir ProjectName" to get a 'somedir/projectname' directory containing the source of the named project. You can then tar that up. Note that the directory name under somedir will always be *lower case*, and it must not exist beforehand. ("somedir" must exist, though.) From rpmuller at gmail.com Tue Dec 4 00:07:55 2007 From: rpmuller at gmail.com (Rick Muller) Date: Mon, 3 Dec 2007 16:07:55 -0700 Subject: [Distutils] Distutils help needed with sub-packages Message-ID: [Posted to c.l.python this morning, but I didn't get any response, so I'm retrying here. Apologies to anyone offended by the cross-posting.] I need some distutils help. I currently run a python library (PyQuante) that, until recently, had all of its modules in a single directory, called "PyQuante". The setup command in my setup.py module had a single "packages" line: packages = ['PyQuante'], I moved some of the routines into Basis and IO subdirectories of PyQuante, and amended the packages line to be: packages = ['PyQuante','PyQuante.Basis','PyQuante.IO'], Everything works find if I'm installing from SVN. However, when I build a tarball via setup.py sdist, the Basis and IO subdirectories are not included. How can I get the distutils to include this? Thanks in advance, Rick -- Rick Muller rpmuller at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20071203/32255ac3/attachment.htm From jeremit0 at gmail.com Tue Dec 4 22:55:18 2007 From: jeremit0 at gmail.com (Jeremy Conlin) Date: Tue, 4 Dec 2007 16:55:18 -0500 Subject: [Distutils] What is the current status of distutils with SWIG and C++? Message-ID: <3db594f70712041355n6f2ef36ctd40029b9fe3d9b2a@mail.gmail.com> Hello all, I have been searching far and wide to find out how to get distutils to work nicely with SWIG and C++. I have an extension written in C++. When I use distutils via a setup.py script I run into problems because swig creates a *_wrap.c file and I want a *_wrap.cxx file. I have added the '-c++' option to my swig_opts variable, but it doesn't fix that problem, but it does pass the option to swig. The swig command that is executed is swigging Material.i to Material_wrap.c swig -python -c++ -o Material_wrap.c Material.i What can I do to make this work? I have read in the archives about some patches that were intended to remedy this situation. Did these patches ever make it into the final distribution? Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20071204/8cd4d4aa/attachment.htm From dpeterson at enthought.com Thu Dec 6 21:15:15 2007 From: dpeterson at enthought.com (Dave Peterson) Date: Thu, 06 Dec 2007 14:15:15 -0600 Subject: [Distutils] Sandbox violation help Message-ID: <47585853.7040407@enthought.com> A user is trying to install Enthought's ETS projects on a Gentoo system and getting the following error message. I'm not seeing it on my systems, but then I'm not running Gentoo. Can anyone give me a clue as to what might be happening or how to go about determining what is happening? The error message has me really confused since 'temp/tmpTTJH2x/zZe82A' doesn't really give me much to go on as to what is being attempted outside of the sandbox. It doesn't help that one line makes it clear something is going on with a tmp directory for enthought.traits but then after that is the error about a tmp dir for enthought.tvtk. How'd we get back to enthought.tvtk in the middle of the enthought.traits install? -- Dave PS: 'enthought.traits' is one of the install_requires dependencies of 'enthought.tvtk' so easy_install probably just chained to building and installing it after enthought.tvtk, right? PPS: I do believe other users have reported the same issues on other systems but we've never quite figured out what the cause is. IIRC, telling them to manually download the source tarball and do a 'python setup.py install' seems to work just fine. > Processing enthought.traits-2.0.1b1.tar.gz > Running enthought.traits-2.0.1b1/setup.py -q bdist_egg --dist-dir > /tmp/easy_install-Edu8TK/enthought.traits-2.0.1b1/egg-dist-tmp-IIITHW > error: Setup script exited with error: SandboxViolation: > open('/tmp/easy_install-WZrKOz/enthought.tvtk-2.0.0b2/temp/tmpTTJH2x/zZe82A > ', 131266, 384) {} > > The package setup script has attempted to modify files on your system > that are not within the EasyInstall build area, and has been aborted. > > This package cannot be safely installed by EasyInstall, and may not > support alternate installation locations even if you run its setup > script by hand. Please inform the package's author and the EasyInstall > maintainers to find out if a fix or workaround is available. > From pje at telecommunity.com Thu Dec 6 22:17:38 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 06 Dec 2007 16:17:38 -0500 Subject: [Distutils] Sandbox violation help In-Reply-To: <47585853.7040407@enthought.com> References: <47585853.7040407@enthought.com> Message-ID: <20071206211737.73FFE3A405E@sparrow.telecommunity.com> At 02:15 PM 12/6/2007 -0600, Dave Peterson wrote: >PPS: I do believe other users have reported the same issues on other >systems but we've never quite figured out what the cause is. IIRC, >telling them to manually download the source tarball and do a 'python >setup.py install' seems to work just fine. > > > Processing enthought.traits-2.0.1b1.tar.gz > > Running enthought.traits-2.0.1b1/setup.py -q bdist_egg --dist-dir > > /tmp/easy_install-Edu8TK/enthought.traits-2.0.1b1/egg-dist-tmp-IIITHW > > error: Setup script exited with error: SandboxViolation: > > open('/tmp/easy_install-WZrKOz/enthought.tvtk-2.0.0b2/temp/tmpTTJH2x/zZe82A > > ', 131266, 384) {} This looks like a bug that was fixed about a year ago: the sandboxing for os.open() (which is what the above appears to be calling) wouldn't allow you to write files *anywhere*, even if it was under a safe directory location. That would explain why you don't get the problem, but the user does. Check their setuptools version, using: python -c "from pkg_resources import require; print require('setuptools')" The bug was fixed in 0.6c5, so anything older will have this problem with anything that uses os.open() to write files. From dpeterson at enthought.com Thu Dec 6 23:02:23 2007 From: dpeterson at enthought.com (Dave Peterson) Date: Thu, 06 Dec 2007 16:02:23 -0600 Subject: [Distutils] Sandbox violation help In-Reply-To: <20071206211737.73FFE3A405E@sparrow.telecommunity.com> References: <47585853.7040407@enthought.com> <20071206211737.73FFE3A405E@sparrow.telecommunity.com> Message-ID: <4758716F.8040600@enthought.com> Phillip J. Eby wrote: > At 02:15 PM 12/6/2007 -0600, Dave Peterson wrote: >> PPS: I do believe other users have reported the same issues on other >> systems but we've never quite figured out what the cause is. IIRC, >> telling them to manually download the source tarball and do a 'python >> setup.py install' seems to work just fine. >> >> > Processing enthought.traits-2.0.1b1.tar.gz >> > Running enthought.traits-2.0.1b1/setup.py -q bdist_egg --dist-dir >> > /tmp/easy_install-Edu8TK/enthought.traits-2.0.1b1/egg-dist-tmp-IIITHW >> > error: Setup script exited with error: SandboxViolation: >> > >> open('/tmp/easy_install-WZrKOz/enthought.tvtk-2.0.0b2/temp/tmpTTJH2x/zZe82A >> >> > ', 131266, 384) {} > > This looks like a bug that was fixed about a year ago: the sandboxing > for os.open() (which is what the above appears to be calling) wouldn't > allow you to write files *anywhere*, even if it was under a safe > directory location. > > That would explain why you don't get the problem, but the user does. > Check their setuptools version, using: > > python -c "from pkg_resources import require; print > require('setuptools')" > > The bug was fixed in 0.6c5, so anything older will have this problem > with anything that uses os.open() to write files. > Thanks! -- Dave From dpeterson at enthought.com Fri Dec 7 17:53:36 2007 From: dpeterson at enthought.com (Dave Peterson) Date: Fri, 07 Dec 2007 10:53:36 -0600 Subject: [Distutils] Sandbox violation help In-Reply-To: <4758716F.8040600@enthought.com> References: <47585853.7040407@enthought.com> <20071206211737.73FFE3A405E@sparrow.telecommunity.com> <4758716F.8040600@enthought.com> Message-ID: <47597A90.6030002@enthought.com> Dave Peterson wrote: > Phillip J. Eby wrote: > >> At 02:15 PM 12/6/2007 -0600, Dave Peterson wrote: >> >>> PPS: I do believe other users have reported the same issues on other >>> systems but we've never quite figured out what the cause is. IIRC, >>> telling them to manually download the source tarball and do a 'python >>> setup.py install' seems to work just fine. >>> >>> >>>> Processing enthought.traits-2.0.1b1.tar.gz >>>> Running enthought.traits-2.0.1b1/setup.py -q bdist_egg --dist-dir >>>> /tmp/easy_install-Edu8TK/enthought.traits-2.0.1b1/egg-dist-tmp-IIITHW >>>> error: Setup script exited with error: SandboxViolation: >>>> >>>> >>> open('/tmp/easy_install-WZrKOz/enthought.tvtk-2.0.0b2/temp/tmpTTJH2x/zZe82A >>> >>>> ', 131266, 384) {} >>>> >> This looks like a bug that was fixed about a year ago: the sandboxing >> for os.open() (which is what the above appears to be calling) wouldn't >> allow you to write files *anywhere*, even if it was under a safe >> directory location. >> >> That would explain why you don't get the problem, but the user does. >> Check their setuptools version, using: >> >> python -c "from pkg_resources import require; print >> require('setuptools')" >> >> The bug was fixed in 0.6c5, so anything older will have this problem >> with anything that uses os.open() to write files. >> >> > > Thanks! > Well, turns out I was premature on assuming this fixed the problem. The user was originally using 0.6c3 but has since upgraded. Here's the current output from your request as sent back by the user: In [3]: pkg_resources.require("setuptools") Out[3]: [setuptools 0.6c7 (/usr/lib/python2.4/site-packages)] The original user is still reproducibly getting the following error -- it appears to have moved to a different project, but otherwise seems the same to me. In addition, one of our internal developers said he was getting this on one of his machines earlier as well but he was able to work around it by manually building the project in question and then going back to using easy_install to install the rest of the dependencies of the originally requested project. Most of us here are not seeing this error so I'm thinking it isn't something obviously wrong with the setup.py. You can look at the setup.py at : https://svn.enthought.com/enthought/browser/tags/enthought.interpolate_2.0.0b3/setup.py Note that this project does use numpy.distutils' setup function. Perhaps the error has something to do with that? Does anyone have any tips on how to go about debugging what might be wrong? In particular, is there any way to get an idea of what the particular file being opened actually represents? -- Dave > Searching for enthought.interpolate > Reading http://code.enthought.com/enstaller/eggs/source > Best match: enthought.interpolate 2.0.0b3 > Downloading > http://code.enthought.com/enstaller/eggs/source/enthought.interpolate-2.0.0 >b3.tar.gz Processing enthought.interpolate-2.0.0b3.tar.gz > Running enthought.interpolate-2.0.0b3/setup.py -q bdist_egg --dist-dir > /tmp/easy_install-jA35_C/enthought.interpolate-2.0.0b3/egg-dist-tmp-m08e-2 > error: Setup script exited with error: SandboxViolation: > open('/home/hans/.python24_compiled/dummy_TuxOnStage_5383_gODMbl', 131266, > 384) {} > > The package setup script has attempted [...] From pje at telecommunity.com Fri Dec 7 19:12:08 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 07 Dec 2007 13:12:08 -0500 Subject: [Distutils] Sandbox violation help In-Reply-To: <47597A90.6030002@enthought.com> References: <47585853.7040407@enthought.com> <20071206211737.73FFE3A405E@sparrow.telecommunity.com> <4758716F.8040600@enthought.com> <47597A90.6030002@enthought.com> Message-ID: <20071207181203.B30413A405E@sparrow.telecommunity.com> At 10:53 AM 12/7/2007 -0600, Dave Peterson wrote: >Does anyone have any tips on how to go about debugging what might be >wrong? In particular, is there any way to get an idea of what the >particular file being opened actually represents? set DISTUTILS_DEBUG=yes and run it; the error should give you a traceback then, which will tell you more about who's creating the file and why. From lxander.m at gmail.com Fri Dec 7 21:15:08 2007 From: lxander.m at gmail.com (Alexander Michael) Date: Fri, 7 Dec 2007 15:15:08 -0500 Subject: [Distutils] SetupTools: Bug in launcher.c causing gui_scripts not to launch? Message-ID: <525f23e80712071215n3cb01ad7i1495eec16c0d87c4@mail.gmail.com> When installing a gui_script on WinXP I get the error: Could not exec #!c:\Python24\pythonw.exe". It looks like the shebang hasn't been stripped. In http://svn.python.org/projects/sandbox/trunk/setuptools/launcher.c (currently at r59407) should if (is_gui) { /* Use exec, we don't need to wait for the GUI to finish */ execv(python, (const char * const *)(newargs)); return fail("Could not exec %s", python); /* shouldn't get here! */ } read something like: if (is_gui) { /* Use exec, we don't need to wait for the GUI to finish */ execv(ptr, (const char * const *)(newargs)); return fail("Could not exec %s", ptr); /* shouldn't get here! */ } as in /* We *do* need to wait for a CLI to finish, so use spawn */ return spawnv(P_WAIT, ptr, (const char * const *)(newargs)); so that the "#!" is stripped from the executable? Thanks, Alex From robert.kern at gmail.com Fri Dec 7 21:48:33 2007 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 07 Dec 2007 14:48:33 -0600 Subject: [Distutils] Sandbox violation help In-Reply-To: <47597A90.6030002@enthought.com> References: <47585853.7040407@enthought.com> <20071206211737.73FFE3A405E@sparrow.telecommunity.com> <4758716F.8040600@enthought.com> <47597A90.6030002@enthought.com> Message-ID: Dave Peterson wrote: > Most of us here are not seeing this > error so I'm thinking it isn't something obviously wrong with the > setup.py. You can look at the setup.py at : > > https://svn.enthought.com/enthought/browser/tags/enthought.interpolate_2.0.0b3/setup.py > > Note that this project does use numpy.distutils' setup function. Perhaps > the error has something to do with that? enthought.interpolate uses weave to built its extension module. weave uses ~/.python24_compiled as its location for the temporaries. We need to fix weave to not do this, or rewrite the extension not to use weave. The latter is probably best. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From dpeterson at enthought.com Fri Dec 7 22:26:59 2007 From: dpeterson at enthought.com (Dave Peterson) Date: Fri, 07 Dec 2007 15:26:59 -0600 Subject: [Distutils] Sandbox violation help In-Reply-To: References: <47585853.7040407@enthought.com> <20071206211737.73FFE3A405E@sparrow.telecommunity.com> <4758716F.8040600@enthought.com> <47597A90.6030002@enthought.com> Message-ID: <4759BAA3.6030306@enthought.com> Robert Kern wrote: > Dave Peterson wrote: > >> Most of us here are not seeing this >> error so I'm thinking it isn't something obviously wrong with the >> setup.py. You can look at the setup.py at : >> >> https://svn.enthought.com/enthought/browser/tags/enthought.interpolate_2.0.0b3/setup.py >> >> Note that this project does use numpy.distutils' setup function. Perhaps >> the error has something to do with that? >> > > enthought.interpolate uses weave to built its extension module. weave uses > ~/.python24_compiled as its location for the temporaries. We need to fix weave > to not do this, or rewrite the extension not to use weave. The latter is > probably best. > > I'm probably just being slow here, but how come the build of enthought.interpolate works for some (I'll assert most here) people but not others? -- Dave From robert.kern at gmail.com Fri Dec 7 23:51:44 2007 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 07 Dec 2007 16:51:44 -0600 Subject: [Distutils] Sandbox violation help In-Reply-To: <4759BAA3.6030306@enthought.com> References: <47585853.7040407@enthought.com> <20071206211737.73FFE3A405E@sparrow.telecommunity.com> <4758716F.8040600@enthought.com> <47597A90.6030002@enthought.com> <4759BAA3.6030306@enthought.com> Message-ID: Dave Peterson wrote: > Robert Kern wrote: >> Dave Peterson wrote: >> >>> Most of us here are not seeing this >>> error so I'm thinking it isn't something obviously wrong with the >>> setup.py. You can look at the setup.py at : >>> >>> https://svn.enthought.com/enthought/browser/tags/enthought.interpolate_2.0.0b3/setup.py >>> >>> Note that this project does use numpy.distutils' setup function. Perhaps >>> the error has something to do with that? >>> >> enthought.interpolate uses weave to built its extension module. weave uses >> ~/.python24_compiled as its location for the temporaries. We need to fix weave >> to not do this, or rewrite the extension not to use weave. The latter is >> probably best. > > I'm probably just being slow here, but how come the build of > enthought.interpolate works for some (I'll assert most here) people but > not others? I don't believe it has ever worked for anyone from easy_install. The sandbox is only active during the easy_install command, not when just running bdist_egg. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From skip at pobox.com Sun Dec 9 07:12:38 2007 From: skip at pobox.com (skip at pobox.com) Date: Sun, 9 Dec 2007 00:12:38 -0600 Subject: [Distutils] Difference between "url" and "download_url"? Message-ID: <18267.34646.4777.681422@montanaro.dyndns.org> I registered a new package at PyPI today, bsddb185. Thinking to check things out, I tried "easy_install bsddb185" and got this output: % easy_install bsddb185 /Users/skip/local/lib/python2.6/site-packages/setuptools-0.6c7-py2.6.egg/setuptools/package_index.py:7: DeprecationWarning: the md5 module is deprecated; use hashlib instead from md5 import md5 Searching for bsddb185 Reading http://pypi.python.org/simple/bsddb185/ Reading http://www.webfast.com/~skip/python/ No local packages or download links found for bsddb185 error: Could not find suitable distribution for Requirement.parse('bsddb185') My setup call looks like this: setup(name='bsddb185', author='Skip Montanaro', author_email='skip at pobox.com', maintainer='Skip Montanaro', maintainer_email='skip at pobox.com', url='http://www.webfast.com/~skip/python/', download_url='http://www.webfast.com/~skip/python/bsddb-1.0.tar.gz', version='1.0', ext_modules=[ext], classifiers=['Development Status :: 6 - Mature', 'Intended Audience :: Developers', 'License :: OSI Approved :: Python Software Foundation License', 'Operating System :: MacOS', 'Operating System :: POSIX', 'Operating System :: POSIX :: BSD', 'Programming Language :: C', 'Programming Language :: Python', 'Topic :: Database', ] ) Why didn't easy_install try the download_url? -- Skip Montanaro - skip at pobox.com - http://www.webfast.com/~skip/ From pje at telecommunity.com Sun Dec 9 15:26:57 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 09 Dec 2007 09:26:57 -0500 Subject: [Distutils] Difference between "url" and "download_url"? In-Reply-To: <18267.34646.4777.681422@montanaro.dyndns.org> References: <18267.34646.4777.681422@montanaro.dyndns.org> Message-ID: <20071209142653.893883A40A4@sparrow.telecommunity.com> At 12:12 AM 12/9/2007 -0600, skip at pobox.com wrote: >My setup call looks like this: > > setup(name='bsddb185', > author='Skip Montanaro', > author_email='skip at pobox.com', > maintainer='Skip Montanaro', > maintainer_email='skip at pobox.com', > url='http://www.webfast.com/~skip/python/', > download_url='http://www.webfast.com/~skip/python/bsddb-1.0.tar.gz', Your tarball is incorrectly named: it should be bsddb185-1.0.tar.gz, since bsddb185 is the package name. If you want to force easy_install to recognize a link to that tarball as being for bsddb185 version 1.0, you must add "#egg=bsddb185-1.0" to the end of the URL. From skip at pobox.com Sun Dec 9 15:34:36 2007 From: skip at pobox.com (skip at pobox.com) Date: Sun, 9 Dec 2007 08:34:36 -0600 Subject: [Distutils] Difference between "url" and "download_url"? In-Reply-To: <20071209142653.893883A40A4@sparrow.telecommunity.com> References: <18267.34646.4777.681422@montanaro.dyndns.org> <20071209142653.893883A40A4@sparrow.telecommunity.com> Message-ID: <18267.64764.119896.431134@montanaro.dyndns.org> >> download_url='http://www.webfast.com/~skip/python/bsddb-1.0.tar.gz', Phillip> Your tarball is incorrectly named: it should be Phillip> bsddb185-1.0.tar.gz, since bsddb185 is the package name. Whoops. Thanks... Skip From kyosohma at gmail.com Tue Dec 11 21:53:55 2007 From: kyosohma at gmail.com (Mike Driscoll) Date: Tue, 11 Dec 2007 14:53:55 -0600 Subject: [Distutils] Compiling MySQL extension Message-ID: Hi, I wanted to give compiling a Windows installer for the Python MySQL extension that I found here: http://sourceforge.net/projects/mysql-python Yes, I know there's already version available for Python 2.4+, but I need the practice. Anyway, I have MySQL-5.0.27 installed on my Windows XP SP2 box and I am using Python 2.4.3. When I go to compile, I get the following: L:\Temp\MySQL-python-1.2.2>python setup.py bdist_wininst {'registry_key': 'SOFTWARE\\MySQL AB\\MySQL Server 5.0', 'static': 'False', 'thr eadsafe': 'True', 'embedded': 'False'} running bdist_wininst running build running build_py creating build creating build\lib.win32-2.4 copying _mysql_exceptions.py -> build\lib.win32-2.4 creating build\lib.win32-2.4\MySQLdb copying MySQLdb\__init__.py -> build\lib.win32-2.4\MySQLdb copying MySQLdb\converters.py -> build\lib.win32-2.4\MySQLdb copying MySQLdb\connections.py -> build\lib.win32-2.4\MySQLdb copying MySQLdb\cursors.py -> build\lib.win32-2.4\MySQLdb copying MySQLdb\release.py -> build\lib.win32-2.4\MySQLdb copying MySQLdb\times.py -> build\lib.win32-2.4\MySQLdb creating build\lib.win32-2.4\MySQLdb\constants copying MySQLdb\constants\__init__.py -> build\lib.win32-2.4\MySQLdb\constants copying MySQLdb\constants\CR.py -> build\lib.win32-2.4\MySQLdb\constants copying MySQLdb\constants\FIELD_TYPE.py -> build\lib.win32-2.4\MySQLdb\constants copying MySQLdb\constants\ER.py -> build\lib.win32-2.4\MySQLdb\constants copying MySQLdb\constants\FLAG.py -> build\lib.win32-2.4\MySQLdb\constants copying MySQLdb\constants\REFRESH.py -> build\lib.win32-2.4\MySQLdb\constants copying MySQLdb\constants\CLIENT.py -> build\lib.win32-2.4\MySQLdb\constants running build_ext building '_mysql' extension Traceback (most recent call last): File "setup.py", line 19, in ? setup(**metadata) File "L:\Python24\lib\distutils\core.py", line 149, in setup dist.run_commands() File "L:\Python24\lib\distutils\dist.py", line 946, in run_commands self.run_command(cmd) File "L:\Python24\lib\distutils\dist.py", line 966, in run_command cmd_obj.run() File "L:\Python24\lib\site-packages\setuptools\command\bdist_wininst.py", line 37, in run _bdist_wininst.run(self) File "L:\Python24\lib\distutils\command\bdist_wininst.py", line 107, in run self.run_command('build') File "L:\Python24\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "L:\Python24\lib\distutils\dist.py", line 966, in run_command cmd_obj.run() File "L:\Python24\lib\distutils\command\build.py", line 112, in run self.run_command(cmd_name) File "L:\Python24\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "L:\Python24\lib\distutils\dist.py", line 966, in run_command cmd_obj.run() File "L:\Python24\lib\site-packages\setuptools\command\build_ext.py", line 46, in run _build_ext.run(self) File "L:\Python24\lib\distutils\command\build_ext.py", line 279, in run self.build_extensions() File "L:\Python24\Lib\site-packages\Pyrex\Distutils\build_ext.py", line 82, in build_extensions self.build_extension(ext) File "L:\Python24\lib\site-packages\setuptools\command\build_ext.py", line 175 , in build_extension _build_ext.build_extension(self,ext) File "L:\Python24\lib\distutils\command\build_ext.py", line 442, in build_exte nsion sources = self.swig_sources(sources, ext) File "L:\Python24\lib\site-packages\setuptools\command\build_ext.py", line 77, in swig_sources sources = _build_ext.swig_sources(self, sources) or sources TypeError: swig_sources() takes exactly 3 arguments (2 given) It looks like it wants a third argument, but I don't know what to give it. Can someone point me in the right direction? Thanks a lot! Mike From S.Pascoe at rl.ac.uk Wed Dec 12 13:41:27 2007 From: S.Pascoe at rl.ac.uk (Pascoe, S (Stephen)) Date: Wed, 12 Dec 2007 12:41:27 -0000 Subject: [Distutils] FW: easy_install bug report Message-ID: I am forwarding the message below from a colleague using easy_install for setuptools-0.6c7. It doesn't appear to set permissions correctly on directories if umask is set to a non-standard value. Alan's suggested default behaviour sounds right to me. Cheers, Stephen. --- Stephen Pascoe +44 (0)1235 445980 British Atmospheric Data Centre Rutherford Appleton Laboratory -----Original Message----- From: Alan Iwi [mailto:A.M.Iwi at rl.ac.uk] Sent: 12 December 2007 08:39 To: Pascoe, S (Stephen) Subject: easy_install bug report Stephen, Please can you pass this on to people who care about such things, as I don't know who to contact. I tried using easy_install while having umask set to 027. (This is the umask that I have set up in my user account, and after "su" the root shell inherited the same umask.) Although it was careful enough to create regular files with world access permissions, it created directories with permissions subject to the umask, i.e. mode 750 rather than 755, so the installed package did not work properly for non-root users. I changed the permissions on the directories and it seems to be otherwise fine. I think that easy_install should create directories with world access, regardless of the umask setting (at least by default, when writing to the shared python directory as root). Thanks, Alan From ziade.tarek at gmail.com Tue Dec 11 18:11:26 2007 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Tue, 11 Dec 2007 18:11:26 +0100 Subject: [Distutils] buildouts upgrades in production Message-ID: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> Hello We are happily using zc.buildout to deploy our Python softwares (mainly zope) in production. The offline mode is very helpfull to create a media with a prepared buildout to deploy the thing on a server that has no web access (this is most of the time the case i guess) Now I am working on the best ways to prepare upgrades for the production and I try to find a way to avoid recreating a big tarball again just for a few changes. My guess is that a snapshot of the download-cache and eggs directory is enough, so a diff can be made to "upgrade" a production server with a tarball of the two directories and the new .cfg But I was wondering if someone had similar experiences already, and maybe a simple, better way ? Thanks Tarek -- Tarek Ziad? | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20071211/cb0e51ad/attachment.htm From tseaver at palladion.com Wed Dec 12 18:11:45 2007 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 12 Dec 2007 12:11:45 -0500 Subject: [Distutils] buildouts upgrades in production In-Reply-To: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> References: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> Message-ID: <47601651.1090901@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziad? wrote: > Hello > > We are happily using zc.buildout to deploy our Python softwares (mainly > zope) in production. > > The offline mode is very helpfull to create a media with a prepared buildout > to deploy the thing on a server that has no web access (this is most of the > time the case i guess) > > Now I am working on the best ways to prepare upgrades for the production and > I try to find a way to avoid recreating a big tarball again just for a few > changes. > > My guess is that a snapshot of the download-cache and eggs directory is > enough, so a diff can be made to "upgrade" a production server with a > tarball of the two directories and the new .cfg > > But I was wondering if someone had similar experiences already, and maybe a > simple, better way ? > > Thanks I would avoid "upgrade in place" scenarios for production use: roll an entirely new deployment into a separate directory, use repozo to dump and reload the ZODB, bring up the new version, test, then switch the port numbers. Just my USD 0.02, Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYBZQ+gerLs4ltQ4RAtWXAKDLmOBq5ZcDFnVbMoknbAZW+cIXTgCgvZlo PFELpT7lPY87E0En4WGCOHI= =5FER -----END PGP SIGNATURE----- From pje at telecommunity.com Wed Dec 12 01:50:55 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 11 Dec 2007 19:50:55 -0500 Subject: [Distutils] Compiling MySQL extension In-Reply-To: References: Message-ID: <20071212171332.340333A40AC@sparrow.telecommunity.com> At 02:53 PM 12/11/2007 -0600, Mike Driscoll wrote: >TypeError: swig_sources() takes exactly 3 arguments (2 given) > >It looks like it wants a third argument, but I don't know what to give >it. Can someone point me in the right direction Either Pyrex, setuptools, or both, are outdated on your system. Check to make sure you have the very latest of both. From tseaver at palladion.com Wed Dec 12 18:11:45 2007 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 12 Dec 2007 12:11:45 -0500 Subject: [Distutils] buildouts upgrades in production In-Reply-To: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> References: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> Message-ID: <47601651.1090901@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziad? wrote: > Hello > > We are happily using zc.buildout to deploy our Python softwares (mainly > zope) in production. > > The offline mode is very helpfull to create a media with a prepared buildout > to deploy the thing on a server that has no web access (this is most of the > time the case i guess) > > Now I am working on the best ways to prepare upgrades for the production and > I try to find a way to avoid recreating a big tarball again just for a few > changes. > > My guess is that a snapshot of the download-cache and eggs directory is > enough, so a diff can be made to "upgrade" a production server with a > tarball of the two directories and the new .cfg > > But I was wondering if someone had similar experiences already, and maybe a > simple, better way ? > > Thanks I would avoid "upgrade in place" scenarios for production use: roll an entirely new deployment into a separate directory, use repozo to dump and reload the ZODB, bring up the new version, test, then switch the port numbers. Just my USD 0.02, Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYBZQ+gerLs4ltQ4RAtWXAKDLmOBq5ZcDFnVbMoknbAZW+cIXTgCgvZlo PFELpT7lPY87E0En4WGCOHI= =5FER -----END PGP SIGNATURE----- From lxander.m at gmail.com Wed Dec 12 19:28:12 2007 From: lxander.m at gmail.com (Alexander Michael) Date: Wed, 12 Dec 2007 13:28:12 -0500 Subject: [Distutils] SetupTools: Bug in launcher.c causing gui_scripts not to launch? In-Reply-To: <525f23e80712071215n3cb01ad7i1495eec16c0d87c4@mail.gmail.com> References: <525f23e80712071215n3cb01ad7i1495eec16c0d87c4@mail.gmail.com> Message-ID: <525f23e80712121028h1a20ac4frcb909fb770609ea7@mail.gmail.com> Has anyone had a change to look at this? Thanks! Alex On Dec 7, 2007 3:15 PM, Alexander Michael wrote: > When trying to run a gui_script on WinXP I get the error: > > Could not exec #!c:\Python24\pythonw.exe". > > It looks like the shebang hasn't been stripped. In > > http://svn.python.org/projects/sandbox/trunk/setuptools/launcher.c > > (currently at r59407) should > > if (is_gui) { > /* Use exec, we don't need to wait for the GUI to finish */ > execv(python, (const char * const *)(newargs)); > return fail("Could not exec %s", python); /* shouldn't get here! */ > } > > read something like: > > if (is_gui) { > /* Use exec, we don't need to wait for the GUI to finish */ > execv(ptr, (const char * const *)(newargs)); > return fail("Could not exec %s", ptr); /* shouldn't get here! */ > } > > as in > > /* We *do* need to wait for a CLI to finish, so use spawn */ > return spawnv(P_WAIT, ptr, (const char * const *)(newargs)); > > so that the "#!" is stripped from the executable? > > Thanks, > Alex From jim at zope.com Thu Dec 13 00:52:06 2007 From: jim at zope.com (Jim Fulton) Date: Wed, 12 Dec 2007 18:52:06 -0500 Subject: [Distutils] buildouts upgrades in production In-Reply-To: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> References: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> Message-ID: On Dec 11, 2007, at 12:11 PM, Tarek Ziad? wrote: > We are happily using zc.buildout to deploy our Python softwares > (mainly zope) in production. Cool. > The offline mode is very helpfull to create a media with a prepared > buildout to deploy the thing on a server that has no web access > (this is most of the time the case i guess) Are you aware of zc.sourcerelease? http://pypi.python.org/pypi/zc.sourcerelease This automates creating buildout-based self-contained source releases that are installed without network access. These source releases can also be used as the basis for system packaging. We use them with a trivial spec file to create RPMs. > Now I am working on the best ways to prepare upgrades for the > production and I try to find a way to avoid recreating a big tarball > again just for a few changes. IMO, the benefit doesn't justify the extra complexity. IMO, deployments should involve as little thought and thus risk as possible. Our RPMs typically install in a few seconds, which is fast enough for me. :) > My guess is that a snapshot of the download-cache and eggs directory > is enough, so a diff can be made to "upgrade" a production server > with a tarball of the two directories and the new .cfg > > But I was wondering if someone had similar experiences already, and > maybe a simple, better way ? There are ways to use a download cache to speed creation of a source release. If you're interested, I could expand on this. Jim -- Jim Fulton Zope Corporation From ziade.tarek at gmail.com Thu Dec 13 10:34:08 2007 From: ziade.tarek at gmail.com (=?UTF-8?Q?Tarek_Ziad=C3=A9?=) Date: Thu, 13 Dec 2007 01:34:08 -0800 (PST) Subject: [Distutils] buildouts upgrades in production In-Reply-To: <47601651.1090901@palladion.com> References: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> <47601651.1090901@palladion.com> Message-ID: <14312704.post@talk.nabble.com> Tres Seaver wrote: > > I would avoid "upgrade in place" scenarios for production use: roll an > entirely new deployment into a separate directory, use repozo to dump > and reload the ZODB, bring up the new version, test, then switch the > port numbers. > What I forgot to mention is that the .fs files where backed up and set back after update, but I didn't thought about using repozo, thanks ! For the upgrade in place, i guess that is just a matter of backing it up before rolling the update, because in most case our updates are done like this: 1/ an apache directive switches users to a admisitrative page outside Zope 2/ the zope directory is backed up in some place 3/ it is updated then tested 4/ the apache is switched back -- View this message in context: http://www.nabble.com/buildouts-upgrades-in-production-tp14296760p14312704.html Sent from the Python - distutils-sig mailing list archive at Nabble.com. From ziade.tarek at gmail.com Thu Dec 13 10:47:59 2007 From: ziade.tarek at gmail.com (=?UTF-8?Q?Tarek_Ziad=C3=A9?=) Date: Thu, 13 Dec 2007 01:47:59 -0800 (PST) Subject: [Distutils] buildouts upgrades in production In-Reply-To: References: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> Message-ID: <14312913.post@talk.nabble.com> Jim Fulton wrote: > > Are you aware of zc.sourcerelease? > > http://pypi.python.org/pypi/zc.sourcerelease > No ! thanks for mentioning it. We did a similar tool that creates tarballs over buildouts (http://pypi.python.org/pypi/iw.releaser) it also works at eggs level to release them, then control that there's no more "develop" section in the buildout, builds it and create a tarball with offline options. (and does svn tags) -> I need to drop the tarball part in favor of zc.sourcerelease I guess Jim Fulton wrote: > >> Now I am working on the best ways to prepare upgrades for the >> production and I try to find a way to avoid recreating a big tarball >> again just for a few changes. > > IMO, the benefit doesn't justify the extra complexity. IMO, > deployments should involve as little thought and thus risk as > possible. Our RPMs typically install in a few seconds, which is fast > enough for me. :) > I agree, but in some cases, my fellows that does upgrades from SSH or Terminal Server are angry because they have to upload a big tarball that often weight > 100 megas just for two changes in some python files. They also argue that sometimes it can be a pain with some firewalls rules. So my idea was to try to make their life easier in that case. The current work consists of creating buildout releases in svn branches after the buildout is created, with a small '.snapshot' file in the folder. It's a shorcut to avoid a complex scanning of .installed.cfg for instance. It lists all folders and files (non recursive) that where collected in the eggs/ folder and the download-cache (and its dist) folders in a flat list. On the next release, the tool knows how to build a small tarball by comparing what is has collected with the .snapshot of the previous release. (work in progress) Jim Fulton wrote: > >> My guess is that a snapshot of the download-cache and eggs directory >> is enough, so a diff can be made to "upgrade" a production server >> with a tarball of the two directories and the new .cfg >> >> But I was wondering if someone had similar experiences already, and >> maybe a simple, better way ? > > > There are ways to use a download cache to speed creation of a source > release. If you're interested, I could expand on this. > I'd love to learn more, please :) ++ Tarek -- View this message in context: http://www.nabble.com/buildouts-upgrades-in-production-tp14296760p14312913.html Sent from the Python - distutils-sig mailing list archive at Nabble.com. From jim at zope.com Thu Dec 13 18:15:21 2007 From: jim at zope.com (Jim Fulton) Date: Thu, 13 Dec 2007 12:15:21 -0500 Subject: [Distutils] buildouts upgrades in production In-Reply-To: <14312913.post@talk.nabble.com> References: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> <14312913.post@talk.nabble.com> Message-ID: On Dec 13, 2007, at 4:47 AM, Tarek Ziad? wrote: > > > Jim Fulton wrote: >> >> Are you aware of zc.sourcerelease? >> >> http://pypi.python.org/pypi/zc.sourcerelease >> > > No ! thanks for mentioning it. We did a similar tool that creates > tarballs > over buildouts (http://pypi.python.org/pypi/iw.releaser) > > it also works at eggs level to release them, then control > that there's no more "develop" section in the buildout, builds > it and create a tarball with offline options. (and does svn tags) > > -> I need to drop the tarball part in favor of zc.sourcerelease I > guess I doubt it. It looks like iw.releaser and zc.sourcerelease are aimed at different, if related, problems. AFAICT, iw.releaser automates some aspects of releasing individual Python distributions. zc.sourcerelease automated releasing course-grained applications, rather individual Python distributions. It assembles necessary Python distributions (and-configure-make-make-install-style distributions) into a single distribution with a Python install script that allows the application to be built and installed from a single download. > Jim Fulton wrote: >> >>> Now I am working on the best ways to prepare upgrades for the >>> production and I try to find a way to avoid recreating a big tarball >>> again just for a few changes. >> >> IMO, the benefit doesn't justify the extra complexity. IMO, >> deployments should involve as little thought and thus risk as >> possible. Our RPMs typically install in a few seconds, which is fast >> enough for me. :) >> > > I agree, but in some cases, my fellows that does upgrades from > SSH or Terminal Server are angry because they have to upload a big > tarball that often weight > 100 megas just for two changes in some > python files. They also argue that sometimes it can be a pain with > some firewalls rules. /me shrugs. ... > Jim Fulton wrote: >> >>> My guess is that a snapshot of the download-cache and eggs directory >>> is enough, so a diff can be made to "upgrade" a production server >>> with a tarball of the two directories and the new .cfg >>> >>> But I was wondering if someone had similar experiences already, and >>> maybe a simple, better way ? >> >> >> There are ways to use a download cache to speed creation of a source >> release. If you're interested, I could expand on this. >> > > I'd love to learn more, please :) I'd like to automate this in the future, but, for now, the following trick works if you know that all of the distributions you need are already in your download cache: buildout-source-release \ svn+ssh://some_repo_url release.cfg \ buildout:index=/home/jim/.buildout/download-cache/dist \ buildout:find-links= \ buildout:extensions= The source-release script takes a URL, usually a subversion URL, for the source to be released and the name of a release configuration file. You can also add additional buildout command-line options. Here, I've specified my download cache as an index. Obviously, you'd need to use a different path. I've also set the find-links and extensions options to empty strings so they aren't used. If you don't use the options in your configuration file, then you don't need to use this and the above would be simplified to: buildout-source-release \ svn+ssh://some_repo_url release.cfg \ buildout:index=/home/jim/.buildout/download-cache/dist With this, the source-release script doesn't have to spend time downloading anything. It does still need to build everything to decide what has to be included. Jim -- Jim Fulton Zope Corporation From ziade.tarek at gmail.com Thu Dec 13 18:46:55 2007 From: ziade.tarek at gmail.com (=?UTF-8?Q?Tarek_Ziad=C3=A9?=) Date: Thu, 13 Dec 2007 09:46:55 -0800 (PST) Subject: [Distutils] buildouts upgrades in production In-Reply-To: References: <94bdd2610712110911w44e10bb1h96aa15b19a6ab217@mail.gmail.com> <14312913.post@talk.nabble.com> Message-ID: <14320894.post@talk.nabble.com> Jim Fulton wrote: > >> >> -> I need to drop the tarball part in favor of zc.sourcerelease I >> guess > > I doubt it. It looks like iw.releaser and zc.sourcerelease are aimed > at different, if related, problems. AFAICT, iw.releaser automates > some aspects of releasing individual Python distributions. > iw.releaser consists of 3 parts (the doc is outdated) : - an entry point for setuptools to add a release command for eggs. This helps developer release one package. but it is just a tool to help releasing. - a project_release script, that create a svn branch for a buildout - a project_deploy that runs bootstrap, bin/buildout then creates a tarball this is the part that does like zc.sourcerelease (see https://ingeniweb.svn.sourceforge.net/svnroot/ingeniweb/iw.releaser/trunk/iw/releaser/project.py) afaik Jim Fulton wrote: > > I'd like to automate this in the future, but, for now, the following > trick works if you know that all of the distributions you need are > already in your download cache: > > buildout-source-release \ > svn+ssh://some_repo_url release.cfg \ > buildout:index=/home/jim/.buildout/download-cache/dist \ > buildout:find-links= \ > buildout:extensions= > > The source-release script takes a URL, usually a subversion URL, for > the source to be released and the name of a release configuration > file. You can also add additional buildout command-line options. > Here, I've specified my download cache as an index. Obviously, you'd > need to use a different path. I've also set the find-links and > extensions options to empty strings so they aren't used. If you don't > use the options in your configuration file, then you don't need to use > this and the above would be simplified to: > > buildout-source-release \ > svn+ssh://some_repo_url release.cfg \ > buildout:index=/home/jim/.buildout/download-cache/dist > > With this, the source-release script doesn't have to spend time > downloading anything. It does still need to build everything to decide > what has to be included. > this is neat ! Tarek -- View this message in context: http://www.nabble.com/buildouts-upgrades-in-production-tp14296760p14320894.html Sent from the Python - distutils-sig mailing list archive at Nabble.com. From zanesdad at bellsouth.net Thu Dec 13 23:15:16 2007 From: zanesdad at bellsouth.net (Jeremy M. Jones) Date: Thu, 13 Dec 2007 17:15:16 -0500 Subject: [Distutils] setuptools and automating deployment of dependent packages Message-ID: <4761AEF4.5010700@bellsouth.net> I am working on some deployment and testing issues with an application at my job. We have one parent package that depends on a number of other packages. I'm working to create an automated build system that checks out the latest revision of each package from Subversion and creates an egg for each (where each has the svn revision number in its version number). The problem is that I'd like to specify exact version numbers in the parent's setup.py for each child package, but I don't know the child svn revision numbers until I start checking things out and I'd really like to automate the process. I could just create a dependency for each child package that states >= some version and when I easyinstall it, it should grab the latest child package from the web server. But that kind of doesn't accomplish what I wanted to do with having a parent package that is specifically tied to some version of a child package. The way that I am considering making this work is to script an update of the setup.py for any package that has child packages that it is checking out of svn. This feels like a big ol' hack. Another alternative is to create a config file (yaml or something else) that setup.py pulls versions from and update that when a parent package becomes aware of a child package's svn revision numbers. So, my questions are: 1. Is there a better way of doing what I'm trying to do than having to hack on setup.py files or modify yaml files? 2. If there's not, how can I tell what version a child package now has (with svn revision number) to know how update the setup.py or config file or what-not? 3. Is there a way to get at the data (version and dependency information is what I'm after) in setup.py? 4. How can I create my own pypi in order to upload eggs to after I've created them? Any assistance anyone could provide would be most appreciated. - jmj From kyosohma at gmail.com Sat Dec 15 15:29:52 2007 From: kyosohma at gmail.com (Mike Driscoll) Date: Sat, 15 Dec 2007 08:29:52 -0600 Subject: [Distutils] Compiling MySQL extension In-Reply-To: <20071212171332.340333A40AC@sparrow.telecommunity.com> References: <20071212171332.340333A40AC@sparrow.telecommunity.com> Message-ID: On Dec 11, 2007 6:50 PM, Phillip J. Eby wrote: > At 02:53 PM 12/11/2007 -0600, Mike Driscoll wrote: > >TypeError: swig_sources() takes exactly 3 arguments (2 given) > > > >It looks like it wants a third argument, but I don't know what to give > >it. Can someone point me in the right direction > > Either Pyrex, setuptools, or both, are outdated on your > system. Check to make sure you have the very latest of both. > > Sorry I didn't respond sooner. It's been nuts at work. Anyway, I have setuptools 0.6c7 and Pyrex 0.9.6.4, as far as I can tell. For some reason, my Pyrex folder isn't labeled with its version number, so I reinstalled it just to be sure. Any other suggestions? Thanks! Mike From billiejoex at gmail.com Thu Dec 20 02:09:58 2007 From: billiejoex at gmail.com (Giampaolo Rodola') Date: Thu, 20 Dec 2007 02:09:58 +0100 Subject: [Distutils] pypi and easy_install Message-ID: <729626cc0712191709g769da316nd0b177455b0c813f@mail.gmail.com> Hi, I noticed tonight that I can't download/install a package of mine hosted on pypi by using easy_install. By running "ez_setup.py pyftpdlib" I get: --- snippet -- options (after parsing config files): no commands known yet options (after parsing command line): option dict for 'aliases' command: {} option dict for 'easy_install' command: {'args': ('command line', ['pyftpdlib']), 'verbose': ('command line', 1)} Searching for pyftpdlib Reading http://pypi.python.org/simple/pyftpdlib/ Reading http://code.google.com/p/pyftpdlib/ No local packages or download links found for pyftpdlib Traceback (most recent call last): File "C:\Documents and Settings\billiejoex\Desktop\ez_setup.py", line 229, in main(sys.argv[1:]) File "C:\Documents and Settings\billiejoex\Desktop\ez_setup.py", line 187, in main main(argv) File "C:\Python25\lib\site-packages\setuptools-0.6c7-py2.5.egg \setuptools\comm and\easy_install.py", line 1670, in main File "C:\Python25\lib\site-packages\setuptools-0.6c7-py2.5.egg \setuptools\comm and\easy_install.py", line 1659, in with_ei_usage File "C:\Python25\lib\site-packages\setuptools-0.6c7-py2.5.egg \setuptools\comm and\easy_install.py", line 1674, in File "C:\Python25\lib\distutils\core.py", line 151, in setup dist.run_commands() File "C:\Python25\lib\distutils\dist.py", line 974, in run_commands self.run_command(cmd) File "C:\Python25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "C:\Python25\lib\site-packages\setuptools-0.6c7-py2.5.egg \setuptools\comm and\easy_install.py", line 211, in run File "C:\Python25\lib\site-packages\setuptools-0.6c7-py2.5.egg \setuptools\comm and\easy_install.py", line 440, in easy_install distutils.errors.DistutilsError: Could not find suitable distribution for Requir ement.parse('pyftpdlib') --- /snippet -- I noticed the following lines: > Searching for pyftpdlib > Reading http://pypi.python.org/simple/pyftpdlib/ > Reading http://code.google.com/p/pyftpdlib/ > No local packages or download links found for pyftpdlib ...which are very weird since, as you can see by looking here: http://pypi.python.org/pypi/pyftpdlib/0.2.0 ...I provided a download url and easy_install SHOULD know where to get the package. Could someone point me in the right direction? From pje at telecommunity.com Thu Dec 20 04:42:17 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 19 Dec 2007 22:42:17 -0500 Subject: [Distutils] pypi and easy_install In-Reply-To: <729626cc0712191709g769da316nd0b177455b0c813f@mail.gmail.co m> References: <729626cc0712191709g769da316nd0b177455b0c813f@mail.gmail.com> Message-ID: <20071220034213.315F63A40A4@sparrow.telecommunity.com> At 02:09 AM 12/20/2007 +0100, Giampaolo Rodola' wrote: >Hi, >I noticed tonight that I can't download/install a package of mine >hosted on pypi by using easy_install. >By running "ez_setup.py pyftpdlib" I get: > >--- snippet -- >options (after parsing config files): >no commands known yet >options (after parsing command line): >option dict for 'aliases' command: > {} >option dict for 'easy_install' command: > {'args': ('command line', ['pyftpdlib']), 'verbose': ('command >line', 1)} >Searching for pyftpdlib >Reading http://pypi.python.org/simple/pyftpdlib/ >Reading http://code.google.com/p/pyftpdlib/ That's because your download URL points to http://pyftpdlib.googlecode.com/files/pyftpdlib_0.2.0.tar.gz, which is not a valid distutils-generated filename. (A valid filename for pytftpdblib, version 0.2.0, would be pyftpdlib-0.2.0.tar.gz.) You need to use "setup.py sdist" to generate your source distribution, then it will have the right filename. (You'll also be able to use "setup.py sdist upload" to upload it to PyPI in that case.) From billiejoex at gmail.com Thu Dec 20 04:47:24 2007 From: billiejoex at gmail.com (Giampaolo Rodola') Date: Thu, 20 Dec 2007 04:47:24 +0100 Subject: [Distutils] pypi and easy_install In-Reply-To: <20071220034213.315F63A40A4@sparrow.telecommunity.com> References: <729626cc0712191709g769da316nd0b177455b0c813f@mail.gmail.com> <20071220034213.315F63A40A4@sparrow.telecommunity.com> Message-ID: <729626cc0712191947s18683928s71ec609dfe562166@mail.gmail.com> You're right, the setup.py included in the tarball reports an invalid download url. I fixed the issue in setup.py and used "setup.py register" for uploading the new package on pypi again. As you can see from here: http://pypi.python.org/pypi?name=pyftpdlib&version=0.2.0&:action=disp... ...now the download url is correct, but the problem still remains. :-\ 2007/12/20, Phillip J. Eby : > At 02:09 AM 12/20/2007 +0100, Giampaolo Rodola' wrote: > >Hi, > >I noticed tonight that I can't download/install a package of mine > >hosted on pypi by using easy_install. > >By running "ez_setup.py pyftpdlib" I get: > > > >--- snippet -- > >options (after parsing config files): > >no commands known yet > >options (after parsing command line): > >option dict for 'aliases' command: > > {} > >option dict for 'easy_install' command: > > {'args': ('command line', ['pyftpdlib']), 'verbose': ('command > >line', 1)} > >Searching for pyftpdlib > >Reading http://pypi.python.org/simple/pyftpdlib/ > >Reading http://code.google.com/p/pyftpdlib/ > > That's because your download URL points to > http://pyftpdlib.googlecode.com/files/pyftpdlib_0.2.0.tar.gz, which > is not a valid distutils-generated filename. > > (A valid filename for pytftpdblib, version 0.2.0, would be > pyftpdlib-0.2.0.tar.gz.) > > You need to use "setup.py sdist" to generate your source > distribution, then it will have the right filename. (You'll also be > able to use "setup.py sdist upload" to upload it to PyPI in that case.) > > From zooko at zooko.com Thu Dec 20 05:34:57 2007 From: zooko at zooko.com (zooko) Date: Wed, 19 Dec 2007 21:34:57 -0700 Subject: [Distutils] setuptools docs mention "distutils.log" ? Message-ID: <5C53DDB8-5F53-43E8-80C1-27D285DA261E@zooko.com> Folks: The setuptools page suggests that authors of revision control plugins can use "distutils.log.warn", but my version of distutils has no such name "log". http://docs.python.org/dist/module-distutils.log.html Regards, Zooko From pje at telecommunity.com Thu Dec 20 05:59:19 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 19 Dec 2007 23:59:19 -0500 Subject: [Distutils] pypi and easy_install In-Reply-To: <729626cc0712191947s18683928s71ec609dfe562166@mail.gmail.co m> References: <729626cc0712191709g769da316nd0b177455b0c813f@mail.gmail.com> <20071220034213.315F63A40A4@sparrow.telecommunity.com> <729626cc0712191947s18683928s71ec609dfe562166@mail.gmail.com> Message-ID: <20071220045912.806693A40A4@sparrow.telecommunity.com> At 04:47 AM 12/20/2007 +0100, Giampaolo Rodola' wrote: >You're right, the setup.py included in the tarball reports an invalid >download url. That's not what I said at all. >I fixed the issue in setup.py and used "setup.py register" for >uploading the new package on pypi again. >As you can see from here: >http://pypi.python.org/pypi?name=pyftpdlib&version=0.2.0&:action=disp... >...now the download url is correct, but the problem still remains. :-\ Please read my previous message again, and you will see the answer to your question. easy_install can only install files that were generated using the distutils; it does not support arbitrarily-named archives with arbitrary contents. From billiejoex at gmail.com Thu Dec 20 14:26:06 2007 From: billiejoex at gmail.com (Giampaolo Rodola') Date: Thu, 20 Dec 2007 14:26:06 +0100 Subject: [Distutils] pypi and easy_install In-Reply-To: <20071220045912.806693A40A4@sparrow.telecommunity.com> References: <729626cc0712191709g769da316nd0b177455b0c813f@mail.gmail.com> <20071220034213.315F63A40A4@sparrow.telecommunity.com> <729626cc0712191947s18683928s71ec609dfe562166@mail.gmail.com> <20071220045912.806693A40A4@sparrow.telecommunity.com> Message-ID: <729626cc0712200526q216165d4h5b2d55d59f3fb7db@mail.gmail.com> Oh, I'm sorry, yestarday night it was very late (5:00 AM) and I completely misunderstood what you said. Thanks for your help, I'm going to rename the tarball. 2007/12/20, Phillip J. Eby : > At 04:47 AM 12/20/2007 +0100, Giampaolo Rodola' wrote: > >You're right, the setup.py included in the tarball reports an invalid > >download url. > > That's not what I said at all. > > >I fixed the issue in setup.py and used "setup.py register" for > >uploading the new package on pypi again. > >As you can see from here: > >http://pypi.python.org/pypi?name=pyftpdlib&version=0.2.0&:action=disp... > >...now the download url is correct, but the problem still remains. :-\ > > Please read my previous message again, and you will see the answer to > your question. easy_install can only install files that were > generated using the distutils; it does not support arbitrarily-named > archives with arbitrary contents. > > From pje at telecommunity.com Thu Dec 20 17:53:51 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 20 Dec 2007 11:53:51 -0500 Subject: [Distutils] pypi and easy_install In-Reply-To: <729626cc0712200526q216165d4h5b2d55d59f3fb7db@mail.gmail.co m> References: <729626cc0712191709g769da316nd0b177455b0c813f@mail.gmail.com> <20071220034213.315F63A40A4@sparrow.telecommunity.com> <729626cc0712191947s18683928s71ec609dfe562166@mail.gmail.com> <20071220045912.806693A40A4@sparrow.telecommunity.com> <729626cc0712200526q216165d4h5b2d55d59f3fb7db@mail.gmail.com> Message-ID: <20071220165342.3F72A3A410C@sparrow.telecommunity.com> At 02:26 PM 12/20/2007 +0100, Giampaolo Rodola' wrote: >Oh, I'm sorry, >yestarday night it was very late (5:00 AM) and I completely >misunderstood what you said. >Thanks for your help, I'm going to rename the tarball. It will be better for you in general if you just use "setup.py sdist" to generate your tarballs, as they will then have the right name, and also will include the distutils PKG-INFO. (This is a distutils feature and doesn't require setuptools, although the distutils are a bit trickier to get the tarball to include everything, as you have to explicitly list in MANIFEST.in anything that distutils doesn't automatically pick up. Setuptools on the other hand will automatically include anything that's under revision control in your project, unless you use MANIFEST.in to tell it *not* to. CVS+SVN support is built in, plugins for various other revision control systems can be found on PyPI.) From pje at telecommunity.com Thu Dec 20 17:55:54 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 20 Dec 2007 11:55:54 -0500 Subject: [Distutils] setuptools docs mention "distutils.log" ? In-Reply-To: <5C53DDB8-5F53-43E8-80C1-27D285DA261E@zooko.com> References: <5C53DDB8-5F53-43E8-80C1-27D285DA261E@zooko.com> Message-ID: <20071220165544.03B643A410C@sparrow.telecommunity.com> At 09:34 PM 12/19/2007 -0700, zooko wrote: >Folks: > >The setuptools page suggests that authors of revision control plugins >can use "distutils.log.warn", but my version of distutils has no such >name "log". What version of distutils is that? Python 2.3, 2.4, and 2.5 (the only supported versions at this time) all include a distutils.log module. From zooko at zooko.com Thu Dec 20 18:35:44 2007 From: zooko at zooko.com (zooko) Date: Thu, 20 Dec 2007 10:35:44 -0700 Subject: [Distutils] setuptools docs mention "distutils.log" ? In-Reply-To: <20071220165544.03B643A410C@sparrow.telecommunity.com> References: <5C53DDB8-5F53-43E8-80C1-27D285DA261E@zooko.com> <20071220165544.03B643A410C@sparrow.telecommunity.com> Message-ID: On Dec 20, 2007, at 9:55 AM, Phillip J. Eby wrote: > At 09:34 PM 12/19/2007 -0700, zooko wrote: >> Folks: >> >> The setuptools page suggests that authors of revision control plugins >> can use "distutils.log.warn", but my version of distutils has no such >> name "log". > > What version of distutils is that? Python 2.3, 2.4, and 2.5 (the > only supported versions at this time) all include a distutils.log > module. Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import distutils >>> distutils.log Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'log From tseaver at palladion.com Thu Dec 20 20:08:17 2007 From: tseaver at palladion.com (Tres Seaver) Date: Thu, 20 Dec 2007 14:08:17 -0500 Subject: [Distutils] setuptools docs mention "distutils.log" ? In-Reply-To: References: <5C53DDB8-5F53-43E8-80C1-27D285DA261E@zooko.com> <20071220165544.03B643A410C@sparrow.telecommunity.com> Message-ID: <476ABDA1.2080707@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 zooko wrote: > On Dec 20, 2007, at 9:55 AM, Phillip J. Eby wrote: > >> At 09:34 PM 12/19/2007 -0700, zooko wrote: >>> Folks: >>> >>> The setuptools page suggests that authors of revision control plugins >>> can use "distutils.log.warn", but my version of distutils has no such >>> name "log". >> What version of distutils is that? Python 2.3, 2.4, and 2.5 (the >> only supported versions at this time) all include a distutils.log >> module. > > Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) > [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import distutils > >>> distutils.log > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'module' object has no attribute 'log Try 'import distutils.log'. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHar2h+gerLs4ltQ4RAoSdAKCT4np27eEw9gzoYvsMCdcq0QBjuQCfbyH5 2ib4qRFkjn8MFTbemr5CUvE= =5ifs -----END PGP SIGNATURE----- From zooko at zooko.com Thu Dec 20 20:34:48 2007 From: zooko at zooko.com (zooko) Date: Thu, 20 Dec 2007 12:34:48 -0700 Subject: [Distutils] setuptools docs mention "distutils.log" ? In-Reply-To: <476ABDA1.2080707@palladion.com> References: <5C53DDB8-5F53-43E8-80C1-27D285DA261E@zooko.com> <20071220165544.03B643A410C@sparrow.telecommunity.com> <476ABDA1.2080707@palladion.com> Message-ID: <6061C7CE-6306-4084-9221-A1A57808AB87@zooko.com> On Dec 20, 2007, at 12:08 PM, Tres Seaver wrote: > > Try 'import distutils.log'. Thank you. That works. However, since the current python docs warn that distutils.log is deprecated [1], I'm currently using "logging" instead. Is there any reason not to do that? Thanks, Zooko [1] http://docs.python.org/dist/module-distutils.log.html From pje at telecommunity.com Thu Dec 20 20:51:37 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 20 Dec 2007 14:51:37 -0500 Subject: [Distutils] setuptools docs mention "distutils.log" ? In-Reply-To: References: <5C53DDB8-5F53-43E8-80C1-27D285DA261E@zooko.com> <20071220165544.03B643A410C@sparrow.telecommunity.com> Message-ID: <20071220195128.B3A5E3A40AC@sparrow.telecommunity.com> At 10:35 AM 12/20/2007 -0700, zooko wrote: >On Dec 20, 2007, at 9:55 AM, Phillip J. Eby wrote: > >>At 09:34 PM 12/19/2007 -0700, zooko wrote: >>>Folks: >>> >>>The setuptools page suggests that authors of revision control plugins >>>can use "distutils.log.warn", but my version of distutils has no such >>>name "log". >> >>What version of distutils is that? Python 2.3, 2.4, and 2.5 (the >>only supported versions at this time) all include a distutils.log >>module. > >Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) >[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin >Type "help", "copyright", "credits" or "license" for more information. > >>> import distutils > >>> distutils.log >Traceback (most recent call last): > File "", line 1, in >AttributeError: 'module' object has no attribute 'log distutils.log isn't an object in the distutils module, it's a module in the distutils package. Use "import distutils.log" or "from distutils import log". From pje at telecommunity.com Thu Dec 20 20:53:27 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 20 Dec 2007 14:53:27 -0500 Subject: [Distutils] setuptools docs mention "distutils.log" ? In-Reply-To: <6061C7CE-6306-4084-9221-A1A57808AB87@zooko.com> References: <5C53DDB8-5F53-43E8-80C1-27D285DA261E@zooko.com> <20071220165544.03B643A410C@sparrow.telecommunity.com> <476ABDA1.2080707@palladion.com> <6061C7CE-6306-4084-9221-A1A57808AB87@zooko.com> Message-ID: <20071220195319.F16D23A40AC@sparrow.telecommunity.com> At 12:34 PM 12/20/2007 -0700, zooko wrote: >On Dec 20, 2007, at 12:08 PM, Tres Seaver wrote: > > > > Try 'import distutils.log'. > >Thank you. That works. > >However, since the current python docs warn that distutils.log is >deprecated [1], I'm currently using "logging" instead. Is there any >reason not to do that? Yes. First, that deprecation is unlikely to have any effect before Python 3.0, and second, using "logging" directly will prevent the distutils or setuptools from controlling the verbosity level of your output. In other words you will break the -q/-v options specified on the command line by the user. From papa.eric at free.fr Fri Dec 21 00:27:38 2007 From: papa.eric at free.fr (Papa Eric) Date: Fri, 21 Dec 2007 00:27:38 +0100 Subject: [Distutils] easy_install and packages with both egg and non-egg distributions Message-ID: <476AFA6A.4060908@free.fr> Hello, From the documentation, unless the --upgrade option is used (or, I suppose, a version specifier given), easy_install is supposed to be content with distributions already installed on sys.path or site-packages. But is it true also when an egg distribution is available for this same package? My problem: I have a dependency on a package xxx which is already installed (as a subdirectory of site-packages). If I put "install_requires = ['xxx']" in some setup.py, the egg will be downloaded. If I try "easy_install xxx" directly, this will force the egg distribution, too. I don't want the egg version because it does not work, import fails on "zipimport.ZipImportError: can't find module 'xxx'" (yet unzipping the egg the xxx packages is there, if anyone has an idea of what may be missing...). Also, if I remove the installed egg to used the existing distribution of xxx, my installed package now works well, except the script installed via entry_points, which seem to expect an egg in any case. So I cannot just "correct" the distribution by removing the wrong egg. The current solution I have found is not formally declare the dependency and advise to install xxx before... Is this the expected behaviour? I'm using python 2.5.1, windows xp, setuptools 0.6c7. Thanks for any help. From pje at telecommunity.com Fri Dec 21 01:18:47 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 20 Dec 2007 19:18:47 -0500 Subject: [Distutils] easy_install and packages with both egg and non-egg distributions In-Reply-To: <476AFA6A.4060908@free.fr> References: <476AFA6A.4060908@free.fr> Message-ID: <20071221001839.195B43A40AC@sparrow.telecommunity.com> At 12:27 AM 12/21/2007 +0100, Papa Eric wrote: >I don't want the egg version because it does not work, import fails on >"zipimport.ZipImportError: can't find module 'xxx'" (yet unzipping the >egg the xxx packages is there, if anyone has an idea of what may be >missing...). It appears you have a corrupted egg file; could you perhaps say what 'xxx' stands for here? From python at venix.com Fri Dec 21 02:45:10 2007 From: python at venix.com (Lloyd Kvam) Date: Thu, 20 Dec 2007 20:45:10 -0500 Subject: [Distutils] easy_install and packages with both egg and non-egg distributions In-Reply-To: <20071221001839.195B43A40AC@sparrow.telecommunity.com> References: <476AFA6A.4060908@free.fr> <20071221001839.195B43A40AC@sparrow.telecommunity.com> Message-ID: <1198201510.3282.49.camel@localhost.localdomain> On Thu, 2007-12-20 at 19:18 -0500, Phillip J. Eby wrote: > At 12:27 AM 12/21/2007 +0100, Papa Eric wrote: > >I don't want the egg version because it does not work, import fails on > >"zipimport.ZipImportError: can't find module 'xxx'" (yet unzipping the > >egg the xxx packages is there, if anyone has an idea of what may be > >missing...). > > It appears you have a corrupted egg file; could you perhaps say what > 'xxx' stands for here? Using Linux, I had trouble with zipped eggs when run from the web server. I no longer have copies of the the error messages, but they related to permission problems with unzipping the egg. I realize that this error message does not seem to fit my scenario, but thought it could be worth mentioning. I set my distutils.cfg file to contain:: [easy_install] zip_ok = False > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://www.librarything.com/catalog/dlslug http://www.librarything.com/profile/dlslug http://www.librarything.com/rsshtml/recent/dlslug From dima at hlabs.spb.ru Fri Dec 21 13:22:39 2007 From: dima at hlabs.spb.ru (Dmitry Vasiliev) Date: Fri, 21 Dec 2007 15:22:39 +0300 Subject: [Distutils] Two problems with setuptools Message-ID: <476BB00F.7000209@hlabs.spb.ru> Hello, Today I've encountered the two problems related (?) to setuptools (version 0.6c6 on Ubuntu Linux): 1. For tests and install my package requires the same packages so I write: setup( ... tests_require=["Package1", "Package2"], install_requires=["Package1", "Package2"], ) It seems OK but the problem arrives if I want to test package (python setup.py test) and then install it (python setup.py install). At the test phase the required packages will be downloaded and placed in the current directory. But at the install phase it seems setuptools will be fooled by the previously downloaded packages and doesn't install them correctly. 2. For my setup I need customize 'install_scripts' and 'install_data' commands. I've placed my customized commands in a separate package, create lazily populated dict-like object which import desired modules by request and write: setup( ... cmdclass=aLazilyPopulatedDictLikeObject, setup_requires=["Package"], ) It works fine except the case when I want to place some options in setup.cfg. For 'install_data' it works as expected, but for 'install_scripts' it seems the configuration parses before the required package will be downloaded and my additional options for 'install_scripts' doesn't work. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://mail.python.org/pipermail/distutils-sig/attachments/20071221/fb974399/attachment.pgp From pje at telecommunity.com Fri Dec 21 15:56:25 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 21 Dec 2007 09:56:25 -0500 Subject: [Distutils] Two problems with setuptools In-Reply-To: <476BB00F.7000209@hlabs.spb.ru> References: <476BB00F.7000209@hlabs.spb.ru> Message-ID: <20071221145616.A014A3A40A4@sparrow.telecommunity.com> At 03:22 PM 12/21/2007 +0300, Dmitry Vasiliev wrote: >Hello, > >Today I've encountered the two problems related (?) to setuptools >(version 0.6c6 on Ubuntu Linux): > >1. For tests and install my package requires the same packages so I write: > > setup( > ... > tests_require=["Package1", "Package2"], > install_requires=["Package1", "Package2"], > ) > >It seems OK but the problem arrives if I want to test package (python >setup.py test) and then install it (python setup.py install). At the >test phase the required packages will be downloaded and placed in the >current directory. But at the install phase it seems setuptools will be >fooled by the previously downloaded packages and doesn't install them >correctly. This is a known bug and not an easy one to fix, which is a big part of why it's not fixed yet. :( >2. For my setup I need customize 'install_scripts' and 'install_data' >commands. I've placed my customized commands in a separate package, >create lazily populated dict-like object which import desired modules by >request and write: > > setup( > ... > cmdclass=aLazilyPopulatedDictLikeObject, > setup_requires=["Package"], > ) > >It works fine except the case when I want to place some options in >setup.cfg. For 'install_data' it works as expected, but for >'install_scripts' it seems the configuration parses before the required >package will be downloaded and my additional options for >'install_scripts' doesn't work. I think you should post your actual code here. As far as I can tell, setuptools installs the setup_requires eggs before any configuration parsing can happen. I would suspect something is wrong with either your setup_requires or your "lazily-populated dictlike object". From tseaver at palladion.com Fri Dec 21 18:35:38 2007 From: tseaver at palladion.com (Tres Seaver) Date: Fri, 21 Dec 2007 12:35:38 -0500 Subject: [Distutils] easy_install of django sdist tarball omits data files In-Reply-To: <1193129888.12729.16.camel@charon> References: <1193129888.12729.16.camel@charon> Message-ID: <476BF96A.3070204@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Graham Carlyle wrote: > Hi > > I've been trying to install a sdist tarball of a django svn snapshot > using easy_install but some of the packages data files (the admin > contrib app templates) aren't being installed. I've looked at the > easy_install web page and can't see anything that may help me install > these data files. > > I'm doing this as part of a deployment script that uses easy_install to > install a web apps dependencies into a particular directory. > > Is this a misuse of easy install? django's setup.py doesn't use > setuptools and so easy_install seems to be creating an sdist_egg on the > fly. I'm working round this by just scripting untarring, & "setup.py > install" etc. directly which is ok but it would be simpler if i could > just call easy_install for all my apps dependencies. I just hit the same problem myself. The Django folks decided to quit using setuptools (for reasons which seem incomprehensible to me), and in the process also borked the ability to use easy_install on their now-non-setuptools-basd sdist. The dodgy bit doesn't seem to be their hand-rolled alternative to 'pkg_resources.find_packages'; even run under easy_install, it appears to popluate the 'data_files' structure correctly. Howeveer, when easy_install runs the 'setup()' function (from distutils), it appears that the 'data_files' structure is not being interpreted correctly. This *may* be a setuptools / easy_install bug; I'm not sure. I did find one recent argument for revisiting that decision, which also provides an alternate easy_install-compatible setup.py: http://jannisleidel.com/2007/11/using-django-with-setuptools/ Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHa/lq+gerLs4ltQ4RAs19AKC3XNU7JsPG0icl7VtHnCGzhr1gngCgxm9H XH7pmLvJWDCijTKhX4QmWrs= =QGk1 -----END PGP SIGNATURE----- From noah.gift at gmail.com Fri Dec 21 19:48:27 2007 From: noah.gift at gmail.com (Noah Gift) Date: Fri, 21 Dec 2007 13:48:27 -0500 Subject: [Distutils] easy_install of django sdist tarball omits data files In-Reply-To: <476BF96A.3070204@palladion.com> References: <1193129888.12729.16.camel@charon> <476BF96A.3070204@palladion.com> Message-ID: > > > I did find one recent argument for revisiting that decision, which also > provides an alternate easy_install-compatible setup.py: > > http://jannisleidel.com/2007/11/using-django-with-setuptools/ > > > Tres. I also like Ian's suggestion: With a little hack you can use setuptools with distutils setup.py's. Setuptools monkeypatches distutils.core.setup(), so anything run after you import setuptools gets all the setuptools features. To make use of this you can do: python -c "import setuptools, os; __file__=os.path.abspath('setup.py'); execfile('setup.py')" develop Or whatever command you want to run. Comment by Ian Bicking ? November 26, 2007 @ 10:09 pm It would be interesting to have a monkeypatch toolkit you could use on any badly written setup.py and force it to work the "correct" way. Perhaps a GHOP project? Monkeypatch to egg....? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20071221/14e135c6/attachment.htm From tseaver at palladion.com Fri Dec 21 21:07:53 2007 From: tseaver at palladion.com (Tres Seaver) Date: Fri, 21 Dec 2007 15:07:53 -0500 Subject: [Distutils] easy_install of django sdist tarball omits data files In-Reply-To: References: <1193129888.12729.16.camel@charon> <476BF96A.3070204@palladion.com> Message-ID: <476C1D19.4060201@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Noah Gift wrote: >> >> I did find one recent argument for revisiting that decision, which also >> provides an alternate easy_install-compatible setup.py: >> >> http://jannisleidel.com/2007/11/using-django-with-setuptools/ >> >> >> Tres. > > I also like Ian's suggestion: > > With a little hack you can use setuptools with distutils setup.py's. > Setuptools monkeypatches distutils.core.setup(), so anything run after you > import setuptools gets all the setuptools features. To make use of this you > can do: > > python -c "import setuptools, os; __file__=os.path.abspath('setup.py'); > execfile('setup.py')" develop > > Or whatever command you want to run. > Comment by Ian Bicking ? November 26, > 2007 @ 10:09 > pm That didn't resolve the problem, but it did mvoe it around: I can get to the 'admin' application at that point, but the "root" page is busted, with the following error: Page not found (404) Request Method: GET Request URL: http://localhost:8000/ Using the URLconf defined in rztest.urls, Django tried these URL patterns, in this order: 1. ^admin/ The current URL, /, didn't match any of these. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHbB0Z+gerLs4ltQ4RAjaeAJ9Hsb5aMVqsruMrJQmnE29T5mpDMwCeMlNm KTzooJ2k/R9lGMUEJdIlDGQ= =KcBx -----END PGP SIGNATURE----- From papa.eric at free.fr Fri Dec 21 23:24:02 2007 From: papa.eric at free.fr (Papa Eric) Date: Fri, 21 Dec 2007 23:24:02 +0100 Subject: [Distutils] easy_install and packages with both egg and non-egg distributions In-Reply-To: <1198201510.3282.49.camel@localhost.localdomain> References: <476AFA6A.4060908@free.fr> <20071221001839.195B43A40AC@sparrow.telecommunity.com> <1198201510.3282.49.camel@localhost.localdomain> Message-ID: <476C3D02.8070704@free.fr> >> It appears you have a corrupted egg file; could you perhaps say what >> 'xxx' stands for here? It's pyglet (www.pyglet.org). I'd be glad if I could suggest a patch. Anyway, more generally, is there a known problem of coexistence of egg and subdirectory distributions? (as far as version specifiers are not used) From dima at hlabs.spb.ru Sun Dec 23 17:50:22 2007 From: dima at hlabs.spb.ru (Dmitry Vasiliev) Date: Sun, 23 Dec 2007 16:50:22 +0000 Subject: [Distutils] Two problems with setuptools In-Reply-To: <20071221145616.A014A3A40A4@sparrow.telecommunity.com> References: <476BB00F.7000209@hlabs.spb.ru> <20071221145616.A014A3A40A4@sparrow.telecommunity.com> Message-ID: <476E91CE.5040206@hlabs.spb.ru> Phillip J. Eby wrote: > At 03:22 PM 12/21/2007 +0300, Dmitry Vasiliev wrote: >> It seems OK but the problem arrives if I want to test package (python >> setup.py test) and then install it (python setup.py install). At the >> test phase the required packages will be downloaded and placed in the >> current directory. But at the install phase it seems setuptools will be >> fooled by the previously downloaded packages and doesn't install them >> correctly. > > This is a known bug and not an easy one to fix, which is a big part of > why it's not fixed yet. :( Aah, bad. Can't the "test" command downloads packages in some location which is just temporarily placed on PYTHONPATH? >> It works fine except the case when I want to place some options in >> setup.cfg. For 'install_data' it works as expected, but for >> 'install_scripts' it seems the configuration parses before the required >> package will be downloaded and my additional options for >> 'install_scripts' doesn't work. > > I think you should post your actual code here. As far as I can tell, > setuptools installs the setup_requires eggs before any configuration > parsing can happen. I would suspect something is wrong with either your > setup_requires or your "lazily-populated dictlike object". Actually the problem is easily reproducible with the following code: ---- setup.cfg ---- [install_scripts] some-option=value ------------------- ---- setup.py ---- from setuptools import setup setup( setup_requires=["somemodule"], ) ------------------ I ran "python setup.py install_scripts" (on Windows XP, Python 2.4, setuptools 0.6c7) and got the following traceback: Traceback (most recent call last): File "setup.py", line 7, in ? setup_requires=["somemodule"], File "c:\Python24\lib\distutils\core.py", line 110, in setup _setup_distribution = dist = klass(attrs) File "c:\python24\lib\site-packages\setuptools-0.6c7-py2.4.egg\setuptools\dist.py", line 219, in __init__ self.fetch_build_eggs(attrs.pop('setup_requires')) File "c:\python24\lib\site-packages\setuptools-0.6c7-py2.4.egg\setuptools\dist.py", line 242, in fetch_build_eggs for dist in working_set.resolve( File "c:\python24\lib\site-packages\setuptools-0.6c7-py2.4.egg\pkg_resources.py", line 522, in resolve dist = best[req.key] = env.best_match(req, self, installer) File "c:\python24\lib\site-packages\setuptools-0.6c7-py2.4.egg\pkg_resources.py", line 758, in best_match return self.obtain(req, installer) # try and download/install File "c:\python24\lib\site-packages\setuptools-0.6c7-py2.4.egg\pkg_resources.py", line 770, in obtain return installer(requirement) File "c:\python24\lib\site-packages\setuptools-0.6c7-py2.4.egg\setuptools\dist.py", line 284, in fetch_build_egg cmd.ensure_finalized() File "c:\Python24\lib\distutils\cmd.py", line 117, in ensure_finalized self.finalize_options() File "c:\python24\lib\site-packages\setuptools-0.6c7-py2.4.egg\setuptools\command\easy_install.py" , line 139, in finalize_options ('install_dir', 'script_dir') File "c:\Python24\lib\distutils\cmd.py", line 304, in set_undefined_options src_cmd_obj = self.distribution.get_command_obj(src_cmd) File "c:\Python24\lib\distutils\dist.py", line 851, in get_command_obj self._set_command_options(cmd_obj, options) File "c:\Python24\lib\distutils\dist.py", line 889, in _set_command_options raise DistutilsOptionError, \ distutils.errors.DistutilsOptionError: error in setup.cfg: command 'install_scripts' has no such option 'some_option' -- Dmitry Vasiliev http://hlabs.spb.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mail.python.org/pipermail/distutils-sig/attachments/20071223/6bf7372b/attachment.pgp From barry at python.org Sun Dec 23 23:51:11 2007 From: barry at python.org (Barry Warsaw) Date: Sun, 23 Dec 2007 17:51:11 -0500 Subject: [Distutils] setuptools pain Message-ID: <81AC444D-3502-46CA-A11E-B27356D9B50C@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 setuptools is causing me pain lately. Something's clearly broken, but setuptools is not helping me understand what, or how to fix it. % /opt/local/bin/python2.5 setup.py develop -d staging running develop running egg_info creating mailman.egg-info writing requirements to mailman.egg-info/requires.txt writing mailman.egg-info/PKG-INFO writing top-level names to mailman.egg-info/top_level.txt writing dependency_links to mailman.egg-info/dependency_links.txt writing entry points to mailman.egg-info/entry_points.txt writing manifest file 'mailman.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' writing manifest file 'mailman.egg-info/SOURCES.txt' running build_ext error: /opt/local/lib/python2.5/site-packages/site.py: No such file or directory % /opt/local/bin/python2.5 setup.py develop -d staging running develop running egg_info writing requirements to mailman.egg-info/requires.txt writing mailman.egg-info/PKG-INFO writing top-level names to mailman.egg-info/top_level.txt writing dependency_links to mailman.egg-info/dependency_links.txt writing entry points to mailman.egg-info/entry_points.txt Traceback (most recent call last): File "setup.py", line 100, in 'setuptools_bzr', File "/opt/local/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/opt/local/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/opt/local/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/opt/local/lib/python2.5/site-packages/setuptools/command/ develop.py", line 27, in run self.install_for_development() File "/opt/local/lib/python2.5/site-packages/setuptools/command/ develop.py", line 85, in install_for_development self.run_command('egg_info') File "/opt/local/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/opt/local/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/opt/local/lib/python2.5/site-packages/setuptools/command/ egg_info.py", line 171, in run self.find_sources() File "/opt/local/lib/python2.5/site-packages/setuptools/command/ egg_info.py", line 252, in find_sources mm.run() File "/opt/local/lib/python2.5/site-packages/setuptools/command/ egg_info.py", line 306, in run self.add_defaults() File "/opt/local/lib/python2.5/site-packages/setuptools/command/ egg_info.py", line 333, in add_defaults rcfiles = list(walk_revctrl()) File "/opt/local/lib/python2.5/site-packages/setuptools/command/ sdist.py", line 45, in walk_revctrl for item in ep.load()(dirname): File "/opt/local/lib/python2.5/site-packages/pkg_resources.py", line 1911, in load if require: self.require(env, installer) File "/opt/local/lib/python2.5/site-packages/pkg_resources.py", line 1924, in require working_set.resolve(self.dist.requires(self.extras),env,installer)) File "/opt/local/lib/python2.5/site-packages/pkg_resources.py", line 524, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: zope.interface % rm -rf mailman.egg-info % /opt/local/bin/python2.5 setup.py develop -d staging running develop running egg_info creating mailman.egg-info writing requirements to mailman.egg-info/requires.txt writing mailman.egg-info/PKG-INFO writing top-level names to mailman.egg-info/top_level.txt writing dependency_links to mailman.egg-info/dependency_links.txt writing entry points to mailman.egg-info/entry_points.txt writing manifest file 'mailman.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' writing manifest file 'mailman.egg-info/SOURCES.txt' running build_ext error: /opt/local/lib/python2.5/site-packages/site.py: No such file or directory % rm -rf mailman.egg-info % /usr/local/bin/python2.5 setup.py develop -d staging running develop running egg_info creating mailman.egg-info writing requirements to mailman.egg-info/requires.txt writing mailman.egg-info/PKG-INFO writing top-level names to mailman.egg-info/top_level.txt writing dependency_links to mailman.egg-info/dependency_links.txt writing entry points to mailman.egg-info/entry_points.txt writing manifest file 'mailman.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' writing manifest file 'mailman.egg-info/SOURCES.txt' running build_ext Creating /Users/barry/projects/mailman/rules/staging/site.py Creating /Users/barry/projects/mailman/rules/staging/mailman.egg-link (link to .) Adding mailman 3.0.0a1 to easy-install.pth file Installing bin/disabled script to staging Installing bin/unshunt script to staging Installing bin/set_members script to staging Installing bin/leave script to staging Installing bin/withlist script to staging Installing bin/mailmanctl script to staging Installing bin/cleanarch script to staging Installing bin/owner script to staging Installing bin/config_list script to staging Installing bin/request script to staging Installing bin/make_instance script to staging Installing bin/show_qfiles script to staging Installing bin/export script to staging Installing bin/join script to staging Installing bin/bumpdigests script to staging Installing bin/nightly_gzip script to staging Installing bin/version script to staging Installing bin/genaliases script to staging Installing bin/inject script to staging Installing bin/check_perms script to staging Installing bin/confirm script to staging Installing bin/list_lists script to staging Installing bin/testall script to staging Installing bin/checkdbs script to staging Installing bin/qrunner script to staging Installing bin/find_member script to staging Installing bin/senddigests script to staging Installing bin/list_owners script to staging Installing bin/show_config script to staging Installing bin/rmlist script to staging Installing bin/add_members script to staging Installing bin/post script to staging Installing bin/arch script to staging Installing bin/newlist script to staging Installing bin/gate_news script to staging Installing bin/import script to staging Installing bin/list_members script to staging Installing bin/update script to staging Installing bin/mmsitepass script to staging Installing bin/change_pw script to staging Installing bin/dumpdb script to staging Installing bin/bounces script to staging Installed /Users/barry/projects/mailman/rules Processing dependencies for mailman==3.0.0a1 Searching for zope.interface Reading http://cheeseshop.python.org/pypi/zope.interface/ Reading http://www.python.org/pypi/zope.interface Reading http://cheeseshop.python.org/pypi/zope.interface/3.4.1 Best match: zope.interface 3.4.1 Downloading http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.4.1.tar.gz#md5 =b085f4a774adab688e037ad32fbbf08e Processing zope.interface-3.4.1.tar.gz Running zope.interface-3.4.1/setup.py -q bdist_egg --dist-dir /var/ folders/by/bycjwwYpGcm-aejnq3kFc++++TI/-Tmp-/easy_install-uav8Hc/ zope.interface-3.4.1/egg-dist-tmp-kA-1fu Adding zope.interface 3.4.1 to easy-install.pth file Installed /Users/barry/projects/mailman/rules/staging/ zope.interface-3.4.1-py2.5-macosx-10.3-i386.egg Searching for storm Reading http://cheeseshop.python.org/pypi/storm/ Reading https://storm.canonical.com Reading https://launchpad.net/storm/+download Reading http://cheeseshop.python.org/pypi/storm/0.11 Best match: storm 0.11 Downloading https://launchpad.net/storm/trunk/0.11/+download/storm-0.11-py2.5.egg Processing storm-0.11-py2.5.egg creating /Users/barry/projects/mailman/rules/staging/storm-0.11- py2.5.egg Extracting storm-0.11-py2.5.egg to /Users/barry/projects/mailman/rules/ staging Adding storm 0.11 to easy-install.pth file Installed /Users/barry/projects/mailman/rules/staging/storm-0.11- py2.5.egg Searching for munepy Reading http://cheeseshop.python.org/pypi/munepy/ Reading http://launchpad.net/munepy Reading http://cheeseshop.python.org/pypi/munepy/1.4 Best match: munepy 1.4 Downloading http://pypi.python.org/packages/2.5/m/munepy/munepy-1.4-py2.5.egg#md5 =6c56db2030c1748f329ba3be4340bb35 Processing munepy-1.4-py2.5.egg Moving munepy-1.4-py2.5.egg to /Users/barry/projects/mailman/rules/ staging Adding munepy 1.4 to easy-install.pth file Installed /Users/barry/projects/mailman/rules/staging/munepy-1.4- py2.5.egg Searching for locknix Reading http://cheeseshop.python.org/pypi/locknix/ Reading https://launchpad.net/locknix Reading http://cheeseshop.python.org/pypi/locknix/1.0 Best match: locknix 1.0 Downloading http://pypi.python.org/packages/2.5/l/locknix/locknix-1.0-py2.5.egg#md5 =ebdba8d44cd6221f49580ca10d42dcb8 Processing locknix-1.0-py2.5.egg Moving locknix-1.0-py2.5.egg to /Users/barry/projects/mailman/rules/ staging Adding locknix 1.0 to easy-install.pth file Installed /Users/barry/projects/mailman/rules/staging/locknix-1.0- py2.5.egg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR27mYnEjvBPtnXfVAQIbjAP8D/g4Zajr8jqmCe776iHKg54KmDTvbRLw HsZ2ceNZPLul1/+9fwaWWwaC6rDvo0G3KRoSxYPGpmTlNLx8+6BNU746u4fULuQV pZPhjeEqbF41/Kwda4Yii/F7hlGlyAfnIYwzJCzt5tNZWNfDD2IprrC/CygRCvK+ 4J1SikrE0kU= =yd+P -----END PGP SIGNATURE----- From matt at matt-good.net Mon Dec 24 06:27:26 2007 From: matt at matt-good.net (Matt Good) Date: Sun, 23 Dec 2007 21:27:26 -0800 Subject: [Distutils] easy_install of django sdist tarball omits data files In-Reply-To: <476BF96A.3070204@palladion.com> References: <1193129888.12729.16.camel@charon> <476BF96A.3070204@palladion.com> Message-ID: On Dec 21, 2007, at 9:35 AM, Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Graham Carlyle wrote: >> Hi >> >> I've been trying to install a sdist tarball of a django svn snapshot >> using easy_install but some of the packages data files (the admin >> contrib app templates) aren't being installed. I've looked at the >> easy_install web page and can't see anything that may help me install >> these data files. >> >> I'm doing this as part of a deployment script that uses >> easy_install to >> install a web apps dependencies into a particular directory. >> >> Is this a misuse of easy install? django's setup.py doesn't use >> setuptools and so easy_install seems to be creating an sdist_egg >> on the >> fly. I'm working round this by just scripting untarring, & "setup.py >> install" etc. directly which is ok but it would be simpler if i could >> just call easy_install for all my apps dependencies. > > I just hit the same problem myself. The Django folks decided to quit > using setuptools (for reasons which seem incomprehensible to me), > and in > the process also borked the ability to use easy_install on their > now-non-setuptools-basd sdist. Sigh. From what I read of their complaints they could have all been fixed with a 2-line diff to remove ez_setup from setup.py. I don't see anywhere they had a problem with setuptools itself, just with the bootstrapping provided by ez_setup. I tried replying to Adrian's post about this, but I think my connection dropped so it may not have gone through. If you care about Django setuptools support you should follow up to make sure they realize that they can use setuptools without requiring an internet connection. -- Matt From ziade.tarek at gmail.com Mon Dec 24 13:47:47 2007 From: ziade.tarek at gmail.com (=?UTF-8?Q?Tarek_Ziad=C3=A9?=) Date: Mon, 24 Dec 2007 04:47:47 -0800 (PST) Subject: [Distutils] templates for .cfg in zc.buildout Message-ID: <14487365.post@talk.nabble.com> Hello, I have posted a message earlier about having a way to play with the environment in cfg files (http://www.nabble.com/zc.buildout-:-Playing-with-environment-in-cfg-files-td13577833.html#a13577833) we came up with a simple way to deal with this, using templates for our cfg files. See iw.buildout: https://ingeniweb.svn.sourceforge.net/svnroot/ingeniweb/iw.buildout/trunk/iw/buildout/docs/README.txt This reduces a lot the number of cfg files we need when we work over applications that are installed under win32 and developed by linux users for instance. I would like to propose this enhancement for inclusion in zc.buildout if you think it's a good idea, to avoid maintaining another package on the top of zc.buildout. I guess we could refactor it so it uses either simple string templates, either cheetah templates. ++ Tarek -- View this message in context: http://www.nabble.com/templates-for-.cfg-in-zc.buildout-tp14487365p14487365.html Sent from the Python - distutils-sig mailing list archive at Nabble.com. From pje at telecommunity.com Wed Dec 26 05:58:24 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue, 25 Dec 2007 23:58:24 -0500 Subject: [Distutils] setuptools pain In-Reply-To: <81AC444D-3502-46CA-A11E-B27356D9B50C@python.org> References: <81AC444D-3502-46CA-A11E-B27356D9B50C@python.org> Message-ID: <20071226045814.78DD13A40A9@sparrow.telecommunity.com> At 05:51 PM 12/23/2007 -0500, Barry Warsaw wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >setuptools is causing me pain lately. Something's clearly broken, but >setuptools is not helping me understand what, or how to fix it. > >% /opt/local/bin/python2.5 setup.py develop -d staging >running develop >running egg_info >creating mailman.egg-info >writing requirements to mailman.egg-info/requires.txt >writing mailman.egg-info/PKG-INFO >writing top-level names to mailman.egg-info/top_level.txt >writing dependency_links to mailman.egg-info/dependency_links.txt >writing entry points to mailman.egg-info/entry_points.txt >writing manifest file 'mailman.egg-info/SOURCES.txt' >reading manifest template 'MANIFEST.in' >writing manifest file 'mailman.egg-info/SOURCES.txt' >running build_ext >error: /opt/local/lib/python2.5/site-packages/site.py: No such file or >directory You have a broken setuptools installation in /opt, which is missing site.py. I'm afraid that setuptools isn't designed to gracefully handle the situation where random files are simply missing from the installation. I'm going to guess that it's missing because it was installed using an RPM or some other package put together by someone who had the hubris to assume that I would actually include files in setuptools that aren't *necessary* for its operation, and that it would therefore be "better" for them to remove it. If this is the case, please educate them regarding the error of their ways -- it will be taken more seriously from an actual user bitten by it, than from me. >% rm -rf mailman.egg-info >% /usr/local/bin/python2.5 setup.py develop -d staging I notice here you're using /usr instead of opt, and this worked, so it appears you have two setuptools installations: one working and one not. Be sure to praise the originator of your working installation as much as you shame the culprit responsible for your broken one. :) From ziade.tarek at gmail.com Wed Dec 26 18:48:53 2007 From: ziade.tarek at gmail.com (=?UTF-8?Q?Tarek_Ziad=C3=A9?=) Date: Wed, 26 Dec 2007 09:48:53 -0800 (PST) Subject: [Distutils] enhancing .pypirc file for multiple servers handling Message-ID: <14504516.post@talk.nabble.com> Hello, I am implementing a PyPI-like server, to allow people using it as a cheeseshop alternative. The .pypirc file that is used together with the register command is working just for one server and will not allow having several set of login/password. This can be a problem if you work with several servers. Furthermore, this command is using a hardcoded ?pypi? realm if you look at distutils/commands/register.py: auth.add_password('pypi', host, username, password) I think it could be enhanced in order to hold several login/password for each server, using the host url and the realm (the realm can be queried automatically too). Otherwise all servers have to fake a ?pypi? realm on 401 errors. I can work on a more formal document (some kind of PEP?) to explain the changes needed in the current implementation. I am also willing to spend the time needed to code it (I will code it anyway in a custom package but I think this belongs to distutils because it is intended, as far as i understand it, to work with any server) Regards Tarek -- View this message in context: http://www.nabble.com/enhancing-.pypirc-file-for-multiple-servers-handling-tp14504516p14504516.html Sent from the Python - distutils-sig mailing list archive at Nabble.com. From matiassurdi at gmail.com Wed Dec 26 18:35:42 2007 From: matiassurdi at gmail.com (Matias Surdi) Date: Wed, 26 Dec 2007 18:35:42 +0100 Subject: [Distutils] bdist_wininst build and ez_setup.py Message-ID: Hi, Im building a binary distribution on linux for my project with: # python setup.py bdist_wininst The .exe installer is generated correctly, and runs perfect on the windows xp host, but the problem is that, as this host doesn't have already setuptools installed, it gives an error when running one of the scripts complaining about missing dependencies (pkg_resources, for example). I wonder if, for bdist_wininst builds is there a way to do an auto-installation of setuptools. I've already put: from ez_setup import use_setuptools use_setuptools() in setup.py, but thats seems to work just for installing with #python setup.py install Thanks a lot for your help. From pje at telecommunity.com Wed Dec 26 20:07:54 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 26 Dec 2007 14:07:54 -0500 Subject: [Distutils] bdist_wininst build and ez_setup.py In-Reply-To: References: Message-ID: <20071226190742.6C8A23A4067@sparrow.telecommunity.com> At 06:35 PM 12/26/2007 +0100, Matias Surdi wrote: >Hi, > >Im building a binary distribution on linux for my project with: > ># python setup.py bdist_wininst > > >The .exe installer is generated correctly, and runs perfect on the >windows xp host, but the problem is that, as this host doesn't have >already setuptools installed, it gives an error when running one of the >scripts complaining about missing dependencies (pkg_resources, for example). > >I wonder if, for bdist_wininst builds is there a way to do an >auto-installation of setuptools. You could create a post-install script for the bdist_wininst installer. See the distutils documentation for more details. From eucci.group at gmail.com Fri Dec 28 15:30:47 2007 From: eucci.group at gmail.com (Jeff Shell) Date: Fri, 28 Dec 2007 07:30:47 -0700 Subject: [Distutils] Forcing setuptools options (always unzip, no dependencies) in buildout? Message-ID: <88d0d31b0712280630r509be04etc00472a2ba8bd842@mail.gmail.com> I still can't get a Egg based Zope app/site up and running. The last headache that I ran into before I had to focus on other work was a core Zope egg (zope.filerepresentation, which we use quite heavily) being a Zipfile based egg. In this mode, Zope's configuration machinery can't get config files out of zope.filerepresentation, and all is lost. The only references to 'always unzip' that I could find in zc.buildout are in the API section. I see no configuration directive for this. Is there a way to force this? I'm also thinking of going no-dependencies for a while since I have internal and external eggs that depend on core Zope 3 library eggs. Which I happen to have in a perfectly good (relatively) Zope 3 installation. But since setuptools doesn't know that said installation provides a reasonable 'zope.filerepresentation', 'zope.component', 'zope.app.frobnitz', etc, I feel like I can't use Eggs without going 100% over to a fully egg based setup. Which, as mentioned above, I haven't been able to get working. I'd be willing to give up automatic dependency tracking for a while in order to come up with an interim solution that I could get up and running. But again - I can't find a way to specify "no dependencies" for buildout (either zc.buildout or zc.recipe.egg). Am I missing something? I trying hard to get my little company to move to using released software packages (both internal and external) as our current way of doing things is getting untenable and difficult to maintain. -- Jeff Shell From eucci.group at gmail.com Fri Dec 28 15:48:06 2007 From: eucci.group at gmail.com (Jeff Shell) Date: Fri, 28 Dec 2007 07:48:06 -0700 Subject: [Distutils] Setuptools plans? Message-ID: <88d0d31b0712280648m5034215blefee05791d1379ce@mail.gmail.com> First: why 0.6c7? Can't we just have a 0.6.0 release? what's holding that back? That version number just seems doubly immature (sub-1.0 and "release candidate") and I often wonder what little push is needed to have a normal 0.6 release. Is there a roadmap or general plans for setuptools for the coming year? I have so many frustrations with the tool, but it's also something that I think I need. So I'd like to get involved if there's any active development or momentum. Right now, though, it doesn't seem like there is any of either. Same thing goes for buildout: any roadmap or plans? What needs to be done to knock that 'beta' off the end and make a 1.0 release? -- Jeff Shell From ziade.tarek at gmail.com Fri Dec 28 16:53:41 2007 From: ziade.tarek at gmail.com (=?UTF-8?Q?Tarek_Ziad=C3=A9?=) Date: Fri, 28 Dec 2007 07:53:41 -0800 (PST) Subject: [Distutils] enhancing .pypirc file for multiple servers handling In-Reply-To: <14504516.post@talk.nabble.com> References: <14504516.post@talk.nabble.com> Message-ID: <14527503.post@talk.nabble.com> Hello, I have create a "iw.dist" package that implements two distutils commands: - mregister - mupload They allow to register and upload packages on several PyPI-like servers, with an ehnanced version of .pypirc (compatible with the old version) For example this .pypirc file adds a new server: [server-login] username:tarek password:secret [local-psc] host: http://localhost:8080/plone/psc username:admin password:admin And I can register/upload my egg both to the cheeseshop and to my local PyPI-like server, like this: $ python setup.py mregister sdist mupload Each command will ask at the prompt for each server if the user wants to perform the call on it. a prototype of iw.dist is available at the cheeseshop ++ Tarek Tarek Ziad? wrote: > > Hello, > > I am implementing a PyPI-like server, to allow people using it as a > cheeseshop alternative. > > The .pypirc file that is used together with the register command is > working just for one server and will not allow having several set of > login/password. This can be a problem if you work with several servers. > > Furthermore, this command is using a hardcoded ?pypi? realm if you look at > distutils/commands/register.py: > > auth.add_password('pypi', host, username, password) > > I think it could be enhanced in order to hold several login/password for > each server, using the host url and the realm (the realm can be queried > automatically too). Otherwise all servers have to fake a ?pypi? realm on > 401 errors. > > I can work on a more formal document (some kind of PEP?) to explain the > changes needed in the current implementation. I am also willing to spend > the time needed to code it (I will code it anyway in a custom package but > I think this belongs to distutils because it is intended, as far as i > understand it, to work with any server) > > Regards > > Tarek > -- View this message in context: http://www.nabble.com/enhancing-.pypirc-file-for-multiple-servers-handling-tp14504516p14527503.html Sent from the Python - distutils-sig mailing list archive at Nabble.com. From eucci.group at gmail.com Fri Dec 28 19:12:27 2007 From: eucci.group at gmail.com (Jeff Shell) Date: Fri, 28 Dec 2007 11:12:27 -0700 Subject: [Distutils] Forcing setuptools options (always unzip, no dependencies) in buildout? In-Reply-To: <64E54632-06B7-4FE5-A707-07BD33BE274E@zope.com> References: <88d0d31b0712280630r509be04etc00472a2ba8bd842@mail.gmail.com> <64E54632-06B7-4FE5-A707-07BD33BE274E@zope.com> Message-ID: <88d0d31b0712281012t65c5323atd72aa006ed4d87c@mail.gmail.com> On Dec 28, 2007 8:40 AM, Jim Fulton wrote: > On Dec 28, 2007, at 9:30 AM, Jeff Shell wrote: > > I still can't get a Egg based Zope app/site up and running. > > That's amazing. I think that some of the problem stems from us using a lot of core Zope 3 bits, and we have to take on some of the core ZCML bootstrapping ourselves (zope.app.zcmlfiles doesn't cover everything that we use). It was as I was going through this bit by bit that I stumbled into the zope.filerepresentation issue. Which I now realize is a non-issue! I just assumed it had a configure.zcml like everything else. Since it was locked away in a zipped egg and I was pressured for time, I never unpacked it to check the contents. I think the issue stemmed from not including it as a dependency, so an import failed. When I added the dependency, I then blindly added an to my app's site.zcml out of habit. OK. I do have a new instance up now. It's a bit messily put together, but I finally see that it can be done with our current software. I can move forward! > A while ago, I pointed you at some working buildouts that used Zope 3 > as eggs. Why not use those as starting points? I did, and they helped. But just to get our core system up and running required some different setups and dependencies that were a little harder to figure out. And I ran into that zope.filerepresentation non-issue right when I ran out of time. Thanks, Jeff Shell From eucci.group at gmail.com Fri Dec 28 19:28:27 2007 From: eucci.group at gmail.com (Jeff Shell) Date: Fri, 28 Dec 2007 11:28:27 -0700 Subject: [Distutils] Buildout plans (Re: Setuptools plans?) In-Reply-To: <110BE137-1A3F-470D-BFC7-97003AE2A58F@zope.com> References: <88d0d31b0712280648m5034215blefee05791d1379ce@mail.gmail.com> <110BE137-1A3F-470D-BFC7-97003AE2A58F@zope.com> Message-ID: <88d0d31b0712281028u5f371de2iee3a7f6ed6a254eb@mail.gmail.com> On Dec 28, 2007 8:43 AM, Jim Fulton wrote: > > On Dec 28, 2007, at 9:48 AM, Jeff Shell wrote: > > Same thing goes for buildout: any roadmap or plans? > > I consider buildout to be pretty mature at this point. I have no plans > for major changes. There are a number of small things I'd like to do > (or would be happy to see others do). What are those small things? I would love to replace the default README.txt used for the PyPI page with something written more like a manual / man page / quickstart. It could be based on what is already written, but just cleaned up. I think the 'zopeproject' page is a good example. I'd like to do this for some of the other core recipes (zc.recipe.filestorage, for example). It's been a while since I've given anything significant (or even insignificant) back to the community besides stressed out ranting and bitching. I think this would be a good place to start. http://cheeseshop.python.org/pypi/zopeproject -- Jeff Shell From zooko at zooko.com Fri Dec 28 19:37:25 2007 From: zooko at zooko.com (zooko) Date: Fri, 28 Dec 2007 11:37:25 -0700 Subject: [Distutils] easy_install of django sdist tarball omits data files In-Reply-To: References: <1193129888.12729.16.camel@charon> <476BF96A.3070204@palladion.com> Message-ID: <72907D26-53B5-4AC6-94F9-121AEC0A41DF@zooko.com> On Dec 23, 2007, at 10:27 PM, Matt Good wrote: > Sigh. From what I read of their complaints they could have all been > fixed with a 2-line diff to remove ez_setup from setup.py. ... > If you care about Django setuptools support you should > follow up to make sure they realize that they can use setuptools > without requiring an internet connection. For what it is worth the allmydata.org tahoe project also requires to be able to install without requiring an internet connection (we call this "The Desert Island Scenario"). This feature was recently broken in tahoe, and with PJE's help I recently fixed it [1]. Other people are, of course, welcome to copy our technique, in which we bundle the setuptools egg itself with our own package. By the way, we actually do this with other 3rd-party libraries upon which we depend, too, which results in a large downloadable (on the order of 5 MB), and which is currently somewhat controversial on our mailing list [2]. Regards, Zooko [1] http://allmydata.org/trac/tahoe/ticket/229 [2] http://allmydata.org/pipermail/tahoe-dev/2007-December/000290.html From barry at python.org Fri Dec 28 19:49:42 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 28 Dec 2007 13:49:42 -0500 Subject: [Distutils] setuptools pain In-Reply-To: <20071226045814.78DD13A40A9@sparrow.telecommunity.com> References: <81AC444D-3502-46CA-A11E-B27356D9B50C@python.org> <20071226045814.78DD13A40A9@sparrow.telecommunity.com> Message-ID: <542CED05-560B-4BCD-AFC1-73BFD5FCB2FD@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phillip, thanks for the response. On Dec 25, 2007, at 11:58 PM, Phillip J. Eby wrote: > At 05:51 PM 12/23/2007 -0500, Barry Warsaw wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> setuptools is causing me pain lately. Something's clearly broken, >> but >> setuptools is not helping me understand what, or how to fix it. >> >> % /opt/local/bin/python2.5 setup.py develop -d staging >> running develop >> running egg_info >> creating mailman.egg-info >> writing requirements to mailman.egg-info/requires.txt >> writing mailman.egg-info/PKG-INFO >> writing top-level names to mailman.egg-info/top_level.txt >> writing dependency_links to mailman.egg-info/dependency_links.txt >> writing entry points to mailman.egg-info/entry_points.txt >> writing manifest file 'mailman.egg-info/SOURCES.txt' >> reading manifest template 'MANIFEST.in' >> writing manifest file 'mailman.egg-info/SOURCES.txt' >> running build_ext >> error: /opt/local/lib/python2.5/site-packages/site.py: No such file >> or >> directory > > You have a broken setuptools installation in /opt, which is missing > site.py. I'm afraid that setuptools isn't designed to gracefully > handle the situation where random files are simply missing from the > installation. Would it be possible to just print the traceback? I haven't looked at the code, but a traceback at least would have helped me narrow down where setuptools was unhappy. The above error message really gives me no clue about where to go next, what to look for, or how to debug and fix the problem. Even a simple "Hey, your setuptools installation is broken, better reinstall it!" would have been very helpful. > I'm going to guess that it's missing because it was installed using > an RPM or some other package put together by someone who had the > hubris to assume that I would actually include files in setuptools > that aren't *necessary* for its operation, and that it would > therefore be "better" for them to remove it. If this is the case, > please educate them regarding the error of their ways -- it will be > taken more seriously from an actual user bitten by it, than from me. This is the MacPorts version of Python, so I guess I have to shame them for busting setuptools. I ended up re-installing it manually to make it happy again. Your explanation about the root problem was helpful in understanding that this was probably the right course of action. :) Maybe I'll try to figure out why the MacPorts version broke. >> % rm -rf mailman.egg-info >> % /usr/local/bin/python2.5 setup.py develop -d staging > > I notice here you're using /usr instead of opt, and this worked, so > it appears you have two setuptools installations: one working and > one not. Be sure to praise the originator of your working > installation as much as you shame the culprit responsible for your > broken one. :) Yes, /usr/local/bin/python2.5 is the one I built and installed from source, so I thank me for a working setuptools installation there! Way to go Barry! :) The other thing I didn't understand is why I got a different error message after the first "setup.py develop" and why it took deleting mailman.egg-info to get the original error message back. Maybe I should look at the setuptools code more carefully. Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR3VFR3EjvBPtnXfVAQJCTAP/esAOA4eigORGEdZghj45sVa5gprBCWaG 6g5O7X3gtp+lHPwc43fI1h3xqeXIZN7WB0I2hlRVRsVKaUfmUHJOTIBcX0suf+5v E9YaZAIywvGAQuuxMrh7qu7uB3QfvxFMRbxZdv7dtLE/a+XGLJ3P3ZezdgLLHkk/ 5uvrJvJnWnE= =YMI4 -----END PGP SIGNATURE----- From pje at telecommunity.com Fri Dec 28 20:30:24 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 28 Dec 2007 14:30:24 -0500 Subject: [Distutils] Forcing setuptools options (always unzip, no dependencies) in buildout? In-Reply-To: <88d0d31b0712280630r509be04etc00472a2ba8bd842@mail.gmail.co m> References: <88d0d31b0712280630r509be04etc00472a2ba8bd842@mail.gmail.com> Message-ID: <20071228193012.E125A3A4067@sparrow.telecommunity.com> At 07:30 AM 12/28/2007 -0700, Jeff Shell wrote: >I still can't get a Egg based Zope app/site up and running. The last >headache that I ran into before I had to focus on other work was a >core Zope egg (zope.filerepresentation, which we use quite heavily) >being a Zipfile based egg. In this mode, Zope's configuration >machinery can't get config files out of zope.filerepresentation, and >all is lost. Note that this means that either: 1. Said configuration machinery should be using pkg_resources APIs to access files, rather than using the filesystem directly, or 2. zope.filerepresentation's setup.py should include zip_safe=False Either one should fix the problem, but I suspect that #1 is what Zope really should do, in order to be fully egg-compatible. From pje at telecommunity.com Fri Dec 28 20:42:27 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri, 28 Dec 2007 14:42:27 -0500 Subject: [Distutils] setuptools pain In-Reply-To: <542CED05-560B-4BCD-AFC1-73BFD5FCB2FD@python.org> References: <81AC444D-3502-46CA-A11E-B27356D9B50C@python.org> <20071226045814.78DD13A40A9@sparrow.telecommunity.com> <542CED05-560B-4BCD-AFC1-73BFD5FCB2FD@python.org> Message-ID: <20071228194214.E31163A4067@sparrow.telecommunity.com> At 01:49 PM 12/28/2007 -0500, Barry Warsaw wrote: >Would it be possible to just print the traceback? You can set the DISTUTILS_DEBUG environment variable to get tracebacks from distutils or setuptools. >This is the MacPorts version of Python, so I guess I have to shame >them for busting setuptools. I ended up re-installing it manually to >make it happy again. Your explanation about the root problem was >helpful in understanding that this was probably the right course of >action. :) Maybe I'll try to figure out why the MacPorts version broke. They took out the 'site.py' file. It's not optional. >The other thing I didn't understand is why I got a different error >message after the first "setup.py develop" and why it took deleting >mailman.egg-info to get the original error message back. Maybe I >should look at the setuptools code more carefully. I'm guessing that your setup.py includes a source-finding entry point. When the .egg-info already exists, the entry point would get called during the egg_info source manifest generation, and it's apparently hitting a missing requirement. When the .egg-info doesn't exist, the entry point wouldn't get called. From barry at python.org Fri Dec 28 21:36:27 2007 From: barry at python.org (Barry Warsaw) Date: Fri, 28 Dec 2007 15:36:27 -0500 Subject: [Distutils] setuptools pain In-Reply-To: <20071228194214.E31163A4067@sparrow.telecommunity.com> References: <81AC444D-3502-46CA-A11E-B27356D9B50C@python.org> <20071226045814.78DD13A40A9@sparrow.telecommunity.com> <542CED05-560B-4BCD-AFC1-73BFD5FCB2FD@python.org> <20071228194214.E31163A4067@sparrow.telecommunity.com> Message-ID: <394FCB2A-711B-4CF6-95E2-CA68A510D519@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 28, 2007, at 2:42 PM, Phillip J. Eby wrote: > At 01:49 PM 12/28/2007 -0500, Barry Warsaw wrote: >> Would it be possible to just print the traceback? > > You can set the DISTUTILS_DEBUG environment variable to get > tracebacks from distutils or setuptools. Good to know, thanks. >> This is the MacPorts version of Python, so I guess I have to shame >> them for busting setuptools. I ended up re-installing it manually to >> make it happy again. Your explanation about the root problem was >> helpful in understanding that this was probably the right course of >> action. :) Maybe I'll try to figure out why the MacPorts version >> broke. > > They took out the 'site.py' file. It's not optional. > > >> The other thing I didn't understand is why I got a different error >> message after the first "setup.py develop" and why it took deleting >> mailman.egg-info to get the original error message back. Maybe I >> should look at the setuptools code more carefully. > > I'm guessing that your setup.py includes a source-finding entry > point. When the .egg-info already exists, the entry point would get > called during the egg_info source manifest generation, and it's > apparently hitting a missing requirement. When the .egg-info > doesn't exist, the entry point wouldn't get called. > Yep, thanks again. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR3VeS3EjvBPtnXfVAQKM/QP+JkaWLWQ5jVjh9G6x2hSSIgl0F+8+JYk9 45HpJ8sTBiJKdjRqfjmITXm4T1EZRtgbPuqRzdgxYEIRBmEl0OHP0LGSCpSbMyxC Hn/rdnbk/aqMRd8QvDLo3KtpSW/4Ek/A/CpbDxN5KufjPnBfYm5qLS6Bs8PoCAaU BIb4y3PCNZY= =4LmM -----END PGP SIGNATURE----- From donn.ingle at gmail.com Mon Dec 31 14:31:38 2007 From: donn.ingle at gmail.com (Donn Ingle) Date: Mon, 31 Dec 2007 15:31:38 +0200 Subject: [Distutils] Distutils confusion - please give me a hand Message-ID: Hi, I have been okay with distutils until my tree got a little bigger, now I am getting errors like: distutils.errors.DistutilsFileError: can't copy 'fontypythonmodules/things/': doesn't exist or not a regular file I confess to being absolutely lost here. I have a few sub-directories inside my package that contain help stuff and locale stuff which I want distutils to include and install. It always worked before, until I invented the help/common/en directory and now it just won't work any more. Here's my tree (warning, monotype font needed): trunk:$ tree . |-- COPYING |-- MANIFEST.in |-- PKG-INFO |-- README |-- fontypython |-- fontypythonmodules | |-- __init__.py | |-- cli.py | |-- dialogues.py | |-- fontcontrol.py | |-- fontybugs.py | |-- fpsys.py | |-- fpversion.py | |-- help | | |-- README | | |-- common | | | |-- README | | | |-- fp1.png.cr.png | | | |-- fp2.png.cr.png | | | |-- fp3.png.cr.png | | | |-- fp4.png.cr.png | | | |-- fp5.png.cr.png | | | |-- fp6.png.cr.png | | | |-- fp7.png.cr.png | | | |-- fp8.png.cr.png | | | |-- fp_already_in_x.png | | | |-- fp_removing_a_font-nq8.png | | | |-- fp_removing_a_font.png | | | |-- fp_ticking.png | | | `-- logo_dec_2007.png | | `-- en | | |-- README | | |-- fp_1to8.png | | |-- fp_pog_icons.cr.png | | `-- help.html | |-- i18n.py | |-- locale | | `-- fr | | `-- LC_MESSAGES | | `-- all.mo | |-- pathcontrol.py | |-- pofiles | | |-- README | | |-- fontypython_translation_template.pot | | `-- fr_all.dec30.pot | |-- pubsub.py | |-- start.py | |-- strings.py | |-- things | | |-- README | | |-- aboutfplogo.png | | |-- cross.png | | |-- fplogo.png | | |-- icon_source_16x16.png | | |-- icon_source_folder_16x16.png | | |-- icon_source_pog_16x16.png | | |-- icon_target_16x16.png | | |-- pog16x16.installed.png | | |-- pog16x16.png | | |-- pog16x16.target.png | | `-- tick.png | `-- wxgui.py |-- fp `-- setup.py Here's my MANIFEST.in include fontypython fp README COPYING recursive-include fontypythonmodules/pofiles * recursive-include fontypythonmodules/things * recursive-include fontypythonmodules/help * recursive-include fontypythonmodules/locale * And here's my basic setup.py, stripped down somewhat: files = ["things/*", "help/*", "help/common/*.*", "help/en/*", "pofiles/*", "locale/fr/LC_MESSAGES/*"] setup(name = "fontypython", packages = ['fontypythonmodules'], package_data = {'fontypythonmodules' : files}, scripts = ["fontypython", "fp"], ....) Weirdly, the path to locale/fr/etc... works just fine. things/* also worked (before I added help). It does not like help/common for some reason I cannot fathom. I have checked case and permissions, but all seems in order. Can anyone point me in the right direction? \d From robin at alldunn.com Mon Dec 31 22:55:27 2007 From: robin at alldunn.com (Robin Dunn) Date: Mon, 31 Dec 2007 13:55:27 -0800 Subject: [Distutils] bugfix for GUI.exe launcher Message-ID: <4779654F.4020502@alldunn.com> I see in the archives that this has been reported before, and I can verify that the attached patch does fix the problem for me. Basically what is happening is that the launcher is trying to execute python with the "#!" still in the name. I verified this by rebuilding gui.exe without -mwindows arg so it would still be a console app so I would see the failure message. It printed this: "Could not exec #!c:\TOOLS\python25\pythonw.exe" -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setuptools-guilauncher.patch Url: http://mail.python.org/pipermail/distutils-sig/attachments/20071231/62f6bd6b/attachment.txt