Mailman 3 June 2006 - Distutils-SIG

Upgrading dependencies
by Charlie Moad 29 Apr '18

29 Apr '18

Is it currently possible to upgrade dependencies as well when upgrading a packages? If not, this would be a really nice feature to add to easy_install. Maybe a call like: easy_install --upgrade --upgrade-deps Package Obviously it makes sense to leave this off by default. Thanks, Charlie

2 1

Changes to --find-links and --upgrade in SVN
by Phillip J. Eby 29 Apr '18

29 Apr '18

Elvelind Grandin reported a problem with the "develop" command that turned out to be a flaw in its --find-links support. Specifically, it wasn't ever processing the links. :) In the process of fixing it, I wound up cleaning up an annoying (to me, at least) quirk of the previous workings of --find-links. It used to be that find-links would always be processed first, no matter what, even if you were doing a completely local operation. This would've been especially annoying if it carried over into "develop", so I made some changes. Now, if an item passed to --find-links is local (a filename or file: URL), or a direct link to an egg or other distribution, it is indexed immediately. Remote URLs are now only retrieved if a dependency can't be resolved locally, or if you use the -U or --upgrade options (this goes for "develop" too). Note that this is a behavior change for easy_install, which was effectively treating --find-links as though you'd specified --upgrade in certain cases. So, if you're used to getting upgrades downloaded as a result of using --find-links, please note that this will no longer happen. EasyInstall will now *only* go online if a dependency can't be resolved locally, if -U or --upgrade is used, or if you provided suitable direct URLs via an argument or --find-links, or via a link in a local .html file.

2 1

Problems with svn in windows
by Sharky On PTNet 29 Apr '18

29 Apr '18

Hi, I´m trying to do "easy_install setuptools==dev" in a windows box but have an error with svn command. """... 'svn' is not recognized as an internal or external command, ...""" I have installed TortoiseSVN but it seems that don't have command line, is all with the Explorer. Can you tell me what client I may use in windows? Thanks for all, Helio Pereira Sharky @ PTNet

3 2

local development scenarios
by tgreenwood 29 Apr '18

29 Apr '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm new to distutils/and the egg system. I have not researched the archives as much as I should, so please excuse me if this is familiar territory... Q: Is it possible for dependency checks to work for non pipy deployed eggs? - A.egg - B.egg (setup_requires and install_requires A.egg) - email A and B eggs to friend - tell friend to : easy_install B - but B.egg does not install A...in fact, in my test case, it fails b/c it cannot find A in pipy - in this example, what happens if friend does not have net connection on target machine? how can they install from the eggs alone and get the dep checking to work? Q: How does my friend run the unittests on the egg that they have just installed? As I am developing, I frequently run the unittests and after every bdist_egg build, I also run the unit tests that way, too. How can the consumer do the same? Q: One of my apps is a command line app, say foo.py is a command line app that takes arg1, arg2,... How can the user run this app when it is encased in an egg? Q: How do I define my own pipy? While I like the idea of deploying there for the overall community, I don't want to send my half baked code into the wild. But I'd like to try the general functionality of having a deploy site for my beta customers. How can I set this up? Thanks in advance. - -Todd -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDl9Hfz6uXX4lQc/URAnY4AJ47DFHL/cpEltmqoUyGqzhsK5FjRACgt01v akc3Wh3IOXVv2jiS8TszhuE= =Rv/x -----END PGP SIGNATURE-----

5 12

Choice of dependencies?
by John J Lee 29 Apr '18

29 Apr '18

Is it possible for a package to depend on one of several packages, with the user having the option to pick? For example, my package P might depend on package A, plus either package B or package C. I know I could (ab)use extras_require, but in my case this is a real dependency rather than an optional extra. The other option I have is to just pick one of the dependencies (B or C in my example above), and thereby force people to install it even though it's not strictly required. Neither option seems particularly attractive. John

3 6

setuptools doc patch
by John J Lee 29 Apr '18

29 Apr '18

The comma removed by the patch below implies that users working from a Subversion checkout should not use EasyInstall to periodically fetch the latest version. That's not what you intended to say, I assume? http://peak.telecommunity.com/DevCenter/setuptools You should also inform your users of the need to run this command, if they -are working from a Subversion checkout, rather than using EasyInstall to +are working from a Subversion checkout rather than using EasyInstall to periodically fetch the latest version. Hmm, probably much better than the patch above: -You should also inform your users of the need to run this command, if they -are working from a Subversion checkout, rather than using EasyInstall to -periodically fetch the latest version. +If your users are working from a Subversion checkout rather than using +EasyInstall, you should also inform them of the need to run this command +to periodically fetch the latest version. John

2 2

Re: [Distutils] distutils install probs on suse 9.0
by Mats Wichmann 29 Apr '18

29 Apr '18

At 05:43 AM 5/18/2004, David Handy wrote: >On Tue, 18 May 2004, Floris van der Tak wrote: > >> my attempt to install the distutils on suse 9.0 (which provides python >> 2.3) fails: > >Why are you installing distutils on a system that already has Python 2.3 >installed? Python 2.3 normally comes with distutils as part of the Python >standard library. > >Did suse distribute a version of Python that had distutils removed? It should come from python-devel

2 1

Sample setup.py for Numeric Python
by Greg Ward 29 Apr '18

29 Apr '18

Hi again -- [cc'd to Paul Dubois: you said you weren't following the distutils sig anymore, but this directly concerns NumPy and I'd like to get your input!] here's that sample setup.py for NumPy. See below for discussion (and questions!). ------------------------------------------------------------------------ #!/usr/bin/env python # Setup script example for building the Numeric extension to Python. # This does sucessfully compile all the .dlls. Nothing happens # with the .py files currently. # Move this file to the Numerical directory of the LLNL numpy # distribution and run as: # python numpysetup.py --verbose build_ext # # created 1999/08 Perry Stoll __rcsid__ = "$Id: numpysetup.py,v 1.1 1999/09/12 20:42:48 gward Exp $" from distutils.core import setup setup (name = "numerical", version = "0.01", description = "Numerical Extension to Python", url = "http://www.python.org/sigs/matrix-sig/", ext_modules = [ ( '_numpy', { 'sources' : [ 'Src/_numpymodule.c', 'Src/arrayobject.c', 'Src/ufuncobject.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/numpy.def' } ), ( 'multiarray', { 'sources' : ['Src/multiarraymodule.c'], 'include_dirs' : ['./Include'], 'def_file': 'Src/multiarray.def' } ), ( 'umath', { 'sources': ['Src/umathmodule.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/umath.def' } ), ( 'fftpack', { 'sources': ['Src/fftpackmodule.c', 'Src/fftpack.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/fftpack.def' } ), ( 'lapack_lite', { 'sources' : [ 'Src/lapack_litemodule.c', 'Src/dlapack_lite.c', 'Src/zlapack_lite.c', 'Src/blas_lite.c', 'Src/f2c_lite.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/lapack_lite.def' } ), ( 'ranlib', { 'sources': ['Src/ranlibmodule.c', 'Src/ranlib.c', 'Src/com.c', 'Src/linpack.c', ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/ranlib.def' } ), ] ) ------------------------------------------------------------------------ First, what d'you think? Too clunky and verbose? Too much information for each extension? I kind of think so, but I'm not sure how to reduce it elegantly. Right now, the internal data structures needed to compile a module are pretty obviously exposed: is this a good thing? Or should there be some more compact form for setup.py that will be expanded later into the full glory we see above? I've already made one small step towards reducing the amount of cruft by factoring 'include_dirs' out and supplying it directly as a parameter to 'setup()'. (But that needs code not in the CVS archive yet, so I've left the sample setup.py the same for now.) The next thing I'd like to do is get that damn "def_file" out of there. To support it in MSVCCompiler, there's already an ugly hack that unnecessarily affects both the UnixCCompiler and CCompiler classes, and I want to get rid of that. (I refer to passing the 'build_info' dictionary into the compiler classes, if you're familiar with the code -- that dictionary is part of the Distutils extension-building system, and should not propagate into the more general compiler classes.) But I don't want to give these weird "def file" things standing on the order of source files, object files, libraries, etc., because they seem to me to be a bizarre artifact of one particular compiler, rather than something present in a wide range of C/C++ compilers. Based on the NumPy model, it seems like there's a not-too-kludgy way to handle this problem. Namely: if building extension "foo": if file "foo.def" found in same directory as "foo.c" add "/def:foo.def" to MSVC command line this will of course require some platform-specific code in the build_ext command class, but I figured that was coming eventually, so why put it off? ;-) To make this hack work with NumPy, one change would be necessary: rename Src/numpy.def to Src/_numpy.def to match Src/_numpy.c, which implements the _numpy module. Would this be too much to ask of NumPy? (Paul?) What about other module distributions that support MSVC++ and thus ship with "def" files? Could they be made to accomodate this scheme? Thanks for your feedback -- Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

4 5

Can now compile simple extensions
by Greg Ward 29 Apr '18

29 Apr '18

Hi all -- at long last, I found the time to hack in the ability to compile extension modules to the Distutils. Mainly, this meant adding a 'build_ext' command which uses a CCompiler instance for all its dirty work. I also had to add a few methods to CCompiler (and, of course, UnixCCompiler) to make this work. And I added a new module, 'spawn', which takes care of running sub-programs more efficiently and robustly (no shell involved) than os.system. That's needed, obviously, so we can run the compiler! If you're in the mood for grubbing over raw source code, then get the latest from CVS or download a current snapshot. See http://www.python.org/sigs/distutils-sig/implementation.html for a link to the code snapshot. I'm still waiting for more subclasses of CCompiler to appear. At the very least, we're going to need MSVCCompiler to build extensions on Windows. Any takers? Also, someone who knows the Mac, and how to run compilers programmatically there, will have to figure out how to write a Mac-specific concrete CCompiler subclass. The spawn module also needs a bit of work to be portable. I suspect that _win32_spawn() (the intended analog to my _posix_spawn()) will be easy to implement, if it even needs to go in a separate function at all. It looks from the Python Library documentation for 1.5.2 that the os.spawnv() function is all we need, but it's a bit hard to figure out just what's needed. Windows wizards, please take a look at the 'spawn()' function and see if you can make it work on Windows. As for actually compiling extensions: well, if you can figure out the build_ext command, go ahead and give it a whirl. It's a bit cryptic right now, since there's no documentation and no example setup.py. (I have a working example at home, but it's not available online.) If you feel up to it, though, see if you can read the code and figure out what's going on. I'm just hoping *I'll* be able to figure out what's going on when I get back from the O'Reilly conference next week... ;-) Enjoy -- Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Two fixes (at last)
by Greg Ward 29 Apr '18

29 Apr '18

Hi all -- at long last, I have fixed two problems that a couple people noticed a while ago: * I folded in Amos Latteier's NT patches almost verbatim -- just changed an `os.path.sep == "/"' to `os.name == "posix"' and added some comments bitching about the inadequacy of the current library installation model (I think this is Python's fault, but for now Distutils is slavishly aping the situation in Python 1.5.x) * I fixed the problem whereby running "setup.py install" without doing anything else caused a crash (because 'build' hadn't yet been run). Now, the 'install' command automatically runs 'build' before doing anything; to make this bearable, I added a 'have_run' dictionary to the Distribution class to keep track of which commands have been run. So now not only are command classes singletons, but their 'run' method can only be invoked once -- both restrictions enforced by Distribution. The code is checked into CVS, or you can download a snapshot at http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz Hope someone (Amos?) can try the new version under NT. Any takers for Mac OS? BTW, all parties involved in the Great "Where Do We Install Stuff?" Debate should take a good, hard look at the 'set_final_options()' method of the Install class in distutils/install.py; this is where all the policy decisions about where to install files are made. Currently it apes the Python 1.5 situation as closely as I could figure it out. Obviously, this is subject to change -- I just don't know to *what* it will change! Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Package versioning
by Timothy Docker 29 Apr '18

29 Apr '18

Hi all, I've been aware that the distutils sig has been simmerring away, but until recently it has not been directly relevant to what I do. I like the look of the proposed api, but have one question. Will this support an installed system that has multiple versions of the same package installed simultaneously? If not, then this would seem to be a significant limitation, especially when dependencies between packages are considered. Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks. A package is installed with its version number in it's name, and a separate directory is created for an application with links from the unversioned package name to the versioned one. Then I just set the pythonpath to this directory. A sample of what the directory looks like is shown below. I'm sure there is a better solution that this, and I'm not sure that this would work under windows anyway (does windows have symlinks?). So, has this SIG considered such versioning issues yet? Cheers, Tim -------------------------------------------------------------- Tim Docker timd(a)macquarie.com.au Quantative Applications Division Macquarie Bank -------------------------------------------------------------- qad16:qad $ ls -l lib/python/ total 110 drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1 -r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1 dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8 drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1 dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1 dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7 dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1 qad16:qad $ ls -l lib/python/1.1 total 30 lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1 lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8 lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1 lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1 lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3 lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7 lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1

3 2

[Distutils-sig] distutils charter and interscript
by John Skaller 29 Apr '18

29 Apr '18

3 2

setuptools site-package pollution
by Anthony Tarlano 10 Oct '06

10 Oct '06

Hi all.. Firstly, I would like to say thanks for the setuptools package, which I was introduced to after reading about the RuleDispatch package on the IBM developerworks charming python series. Oh btw. RuleDispatch is the most useful python package that I have seen in the last year in the python world, so thanks for that also ;) Now that the congrats and hugs are out of the way, I would like to ask a question. How can I tell setuptools not to put packages, such as dispatch, protocols, and setuptools, in a subdirectory named the same as the egg and to just put the package name. For example from pydoc I currently get: c:\python\lib\site-packages\ruledispatch-0.5a0.dev_r2100-py2.4-win32.egg dispatch (package) c:\python\lib\site-packages\pyprotocols-1.0a0dev_r2082-py2.4-win32.egg dispatch protocols (package) c:\python\lib\site-packages\setuptools-0.6a8-py2.4.egg easy_install pkg_resources setuptools (package) site what I would like to see is just: ..\site-packages dispatch (package) ..\site-packages protocols (package) ..\site-packages setuptools (package) Maybe it is just a pet-peeve, but I like to keep a nice tidy site-packages directory, and these long directory names just seem to me to be pollution of my site-packages directory in my command shell. If there is an option to have just the packages, I would really appreciate someone telling me what it is. If not maybe it could be considered, and to put whatever meta-data the directory names are providing somewhere else.. Thanks, Anthony

3 2

Re: [Distutils] Problem between bdist_msi and egg-info (Python 2.5b1)
by Phillip J. Eby 02 Jul '06

02 Jul '06

At 04:21 PM 6/29/2006 +0100, Paul Moore wrote: > File "D:\Apps\Python25\Lib\msilib\__init__.py", line 115, in add_data > raise MSIError("Could not insert "+repr(values)+" into "+table) >_msi.MSIError: Could not insert [(None, 'site_packages', >'TEST-1~1.EGG|test-1.0-py2.5.egg-info', 186L, None, None, 512, 1)] >into File This line is masking whatever the actual error is. If you look at the source, you'll see it's doing "except Exception,e:" and trapping whatever the real problem is. I'd suggest commenting out the try/except and see what error comes up instead. That should tell us more about the problem. I believe Martin v. Loewis is the author of bdist_msi; I'm not sure if he reads this list or not. Perhaps he will comment.

2 2

Re: [Distutils] Best practices for creating eggs?
by Phillip J. Eby 02 Jul '06

02 Jul '06

At 04:13 PM 6/29/2006 +0100, Paul Moore wrote: >Agreed. But in the absence of a standard, supporting package authors' >existing approaches, which work with other distutils mechanisms, seems >like a reasonable requirement. Anything that the package author installs as package data, or using the data_files option to setup(), is included in the egg. And if you install unzipped, you should be able to browse the included docs.

3 2

Re: [Distutils] Why using distutils.core.setup requires Python sources ?
by Phillip J. Eby 29 Jun '06

29 Jun '06

At 12:03 AM 6/30/2006 +0200, Jérôme Bouat wrote: > > only the contents of "/usr/lib/python2.x/config/" -- the directory where > > Python's build configuration information is copied upon installation. > >Its seems that my Mandriva Linux distro did not package this well: > >[j@localhost ~]$ rpm -q --all | grep --ignore-case python >python-2.4.1-3mdk >python-numeric-24.0-1mdk >python-base-2.4.1-3mdk >libpython2.4-2.4.1-3mdk >libxml2-python-2.6.21-3mdk You might first want to check if there is a 'python-dev' or 'python-devel' package you can install; some distributions only install the 'config' directory with such a package. >[j@localhost ~]$ >[j@localhost ~]$ rpm -q --list $(rpm -q --all | grep --ignore-case >python) | grep --ignore-case makefile >[j@localhost ~]$ >[j@localhost ~]$ locate -i makefile | grep --ignore-case python >/usr/share/doc/libidn11-0.5.18/contrib/idn-python/Makefile >[j@localhost ~]$ >[j@localhost ~]$ rpm -q >--whatprovides /usr/share/doc/libidn11-0.5.18/contrib/idn-python/Makefile >libidn11-0.5.18-2mdk >[j@localhost ~]$ > >Maybe I should report this as a Mandriva bug. What you've shown above is an unrelated Makefile. It's likely that the needed 'config' directory is installed by another package that you don't currently have installed. If there is no such package, or it doesn't install the 'config' directory, then you should indeed report a bug.

1 0

Re: [Distutils] Why using distutils.core.setup requires Python sources ?
by Phillip J. Eby 29 Jun '06

29 Jun '06

At 10:39 PM 6/29/2006 +0200, Jérôme Bouat wrote: >Thanks for your reply. > >Thus, distutils is not designed for distributing a module outside the >Python source repository ? I don't understand your question. When Python is installed, it installs a copy of the Makefile that was used to create that Python installation. So this has nothing to do with the source directory used to compile Python, only the contents of "/usr/lib/python2.x/config/" -- the directory where Python's build configuration information is copied upon installation.

1 0

Weird PyPI Behavior
by Jim Fulton 29 Jun '06

29 Jun '06

If I do something like: python2.4 setup.py register bdist_egg upload as recommended in the setuptools documentation, I end up with 2 "releases" in PyPi. One has all my descriptive information and the other has the egg. One or more will or won't be hidden according some rule that I haven't been able to divine. If the release with the meta data (e.g. description, author, etc.) is not hidden, then easy_install can't seem to find the eggs. At least this is true today. I thought it wasn't true yesterday, but I don't trust my recollection. If I hide the release with the descriptive information, then easy_install can find the eggs, but most of my meta data isn't shown. Has anyone else seen this behavior, or am I just insane. For now, I'm not uploading eggs to PyPI, which is a shame, because setuptools sure made it convenient. :( Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 9

Optimize option for windows exe scripts?
by Patrick K. O'Brien 29 Jun '06

29 Jun '06

Is there a way to have the Windows .exe created by setuptools use optimized Python, like "python -O myscript.py"? http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation In particular, I'd like this option to work with a project where I am working out of Subversion using "python setup.py develop". -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org

2 1

Why using distutils.core.setup requires Python sources ?
by Jérôme Bouat 29 Jun '06

29 Jun '06

I don't understand why distutils.core.setup needs Python sources (a missing Makefile on my distro). I did not found in the mail archives. Could you explain me ? Thanks.

2 1

Re: [Distutils] unrecognised swig options ?
by Phillip J. Eby 29 Jun '06

29 Jun '06

At 03:49 PM 6/10/2006 +0800, Risky Martin wrote: >2006/6/7, Risky Martin <<mailto:risky.martin@gmail.com> >risky.martin(a)gmail.com>: >>I am trying to use disutils's features with 'SWIG'... but hit >>a rather strange problem. >> >>To reproduce it: >> >>setup.py >>------------------------------------------------------ >>from distutils.core import setup, Extension >> >>e = Extension("_foo", >> sources = ["foo.i", ], >> swig_opts = ["-outdir .", ]) >> >> >>setup(name="foo", >> ext_modules=[e, ]) >>------------------------------------------------------- >> >>building fails like: >> >> > python setup.py build >>running build >>running build_ext >>building '_foo' extension >>swigging foo.i to foo_wrap.c >>swig -python -outdir . -o foo_wrap.c foo.i >>swig error : Unrecognized option -outdir . >>Use 'swig -help' for available options. >>error: command 'swig' failed with exit status 1 >> >>but a copy/paste of the swig command shows that '-outdir' *is* recognised... >> > swig -python -outdir . -o foo_wrap.c foo.i >>Unable to find file 'foo.i'. Are you sure that you are running the same swig on the command line that Python is running?

1 0

Problem between bdist_msi and egg-info (Python 2.5b1)
by Paul Moore 29 Jun '06

29 Jun '06

If I try to build a bdist_msi installer for a trivial module, using Python 2.5b1, I get an error. It looks like a problem with the interaction of the new (in 2.5) egg-info stuff and the bdist_msi code - but I have no further ideas. Here is the setup.py from distutils.core import setup setup( name='test', version='1.0', py_modules=['test'], ) And here is the build output: >python setup.py bdist_msi running bdist_msi running build running build_py creating build creating build\lib copying test.py -> build\lib installing to build\bdist.win32\msi running install_lib creating build\bdist.win32 creating build\bdist.win32\msi creating build\bdist.win32\msi\Lib creating build\bdist.win32\msi\Lib\site-packages copying build\lib\test.py -> build\bdist.win32\msi\Lib\site-packages running install_egg_info Writing build\bdist.win32\msi\Lib\site-packages\test-1.0-py2.5.egg-info creating dist Traceback (most recent call last): File "setup.py", line 5, in <module> py_modules=['test'], File "D:\Apps\Python25\Lib\distutils\core.py", line 151, in setup dist.run_commands() File "D:\Apps\Python25\Lib\distutils\dist.py", line 974, in run_commands self.run_command(cmd) File "D:\Apps\Python25\Lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "D:\Apps\Python25\Lib\distutils\command\bdist_msi.py", line 235, in run self.add_files() File "D:\Apps\Python25\Lib\distutils\command\bdist_msi.py", line 263, in add_files key = dir.add_file(file) File "D:\Apps\Python25\Lib\msilib\__init__.py", line 343, in add_file language, attributes, sequence)]) File "D:\Apps\Python25\Lib\msilib\__init__.py", line 115, in add_data raise MSIError("Could not insert "+repr(values)+" into "+table) _msi.MSIError: Could not insert [(None, 'site_packages', 'TEST-1~1.EGG|test-1.0-py2.5.egg-info', 186L, None, None, 512, 1)] into File I can't log a SF bug at the moment, as SF isn't accepting logins, but maybe someone could take a look and judge where the problem lies. Then when I can log a bug, I can put it in the right category :-) Thanks, Paul.

1 0

Re: [Distutils] Best practices for creating eggs?
by Phillip J. Eby 29 Jun '06

29 Jun '06

At 10:37 AM 6/29/2006 +0100, Paul Moore wrote: >On 6/28/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: >>I assume that most people will read the docs on the web, and that if they >>want the documentation source, they will download the "sdist" distribution >>that I always upload alongside of the eggs. > >I work offline sufficiently often that not having local documentation >is frustrating. There's no standard for local docs, which is a >nuisance, and makes for an inconsistent story between different >packages, but I'd be concerned if setuptools made it more difficult to >bundle local docs. > >An example - cx_Oracle provides a full set of HTML documentation which >the bdist_wininst installer drops in C:\Python24\cx_Oracle-doc. The >one time I tried using easy_install to convert this to an egg, the >documentation got missed out. I've never retried the experiment, >however, so things could well have changed, as this was quite a while >ago. > >And of course, eggs which get installed as zip files don't really >offer anywhere to *put* documentation which is accessible (web >browsers can't load HTML out of zip files, for example). Note that I said above that I always put the documentation in an sdist form; to obtain a package's source distribution, use: easy_install -e -b somedir arg... Where 'arg...' is some specification of a package, and 'somedir' is the parent directory of where you want the package's source to be unpacked or checked out. If you requested e.g. 'cx_Oracle', you will end up with a 'somedir/cx_oracle' directory containing the extracted source distribution. You can then decide what to do with any docs in it. A standard for how to install documentation would be great, because then you could run the docinstall command or whatever it's called on the source directory. For that matter, easy_install could be made to do it also. (Of course, this could presumably be included in eggs also, but I'm thinking of it being a separate operation from installing the eggs, just because it's increasingly common to be installing a package to satisfy some other package's dependency -- not because you actually intend to use that package directly. OTOH, relatively small packages compared to their documentation size might just want to throw it in.)

2 1

Best practices for creating eggs?
by Jim Fulton 29 Jun '06

29 Jun '06

Has anyone written up any best practices for creating eggs? How do people handle documentation? Our packages tend to have documentation files included as doctests, but It's not clear how folks are expected to get to them, especially if the eggs are zip files. -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

4 4

How does one register a framework classifier?
by Jim Fulton 29 Jun '06

29 Jun '06

How does one register a new Framework classifier? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 4

README(.txt)?
by Jim Fulton 28 Jun '06

28 Jun '06

If I don't have a README or README.txt file next to my setup.py file when I create an edd, I'll get the warning: warning: manifest_maker: standard file not found: should have one of README, README.txt I don't like warnings. So I create a REAME,txt file and then generate an egg and, guess what? It's not included. Bug or feature? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 2

setup.py develop ignores --no-deps option
by Jim Fulton 25 Jun '06

25 Jun '06

AFAICT, with 0.6b3, setup.py develop ignores the --no-deps option. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

conditional external packages dependancies with setuptools
by Jorge Vargas 24 Jun '06

24 Jun '06

sorry forgot to send this to the list. ---------- Forwarded message ---------- From: Jorge Vargas <jorge.vargas(a)gmail.com> Date: Jun 24, 2006 4:13 PM Subject: Re: [Distutils] conditional external packages dependancies with setuptools To: "Phillip J. Eby" <pje(a)telecommunity.com> On 6/24/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: > At 01:29 PM 6/24/2006 -0400, Jorge Vargas wrote: > >On 6/24/06, Phillip J. Eby > ><<mailto:pje@telecommunity.com>pje(a)telecommunity.com > wrote: > >>At 03:04 AM 6/24/2006 -0400, Jorge Vargas wrote: > >> >but What I want to accomplish is having dependancies on some packages. > for > >> >example my project will have diferent database backends so I want to > >> >depend on pysqlite or mysql-python depending on which the user wants > as > >> >his/her backend. I'm going to have lots of diferent backends, even > some > >> >that are not databases, so this will be a crutial thing for me or I'll > end > >> >up with very big dist files per release, which will mostly be waste if > the > >> >user never uses them. > >> > > >> >is something like this possible with setuptools now? > >> > >>Yes: > >> > >><http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras>http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras > >> > > > >there it says that I can set them and then project depending on mine > will > >be able to add them to their install_required, but what I want is my > >project to have it optional > > > >there is a reference that they can be pass as commands to easy_install > but > >can't find the switch at > ><http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options > >http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options > > If you have an optional feature called "bar" for your package named "foo", > you would use: > > easy_install foo[bar] > > if there's also a "baz" feature and the user wants to install that too, > they can use: > > easy_install foo[bar,baz] ahh yes now I remenber TurboGears uses those. will there be a way to create defaults for this or maybe provide diferent "instalation scripts" for example <mypackage>-minimal.py equivalente of easy_install <mypackage> <mypackage>-std.py equivalente of easy_install <mypackage> [for,bar] <mypackage>-full.py equivalente of easy_install <mypackage> [for,bar,baz,bazz] >I'm looking at something like the gentoo's USE flags system. where I can > >have a script or config file that each install will use with the optional > >packages they want, and distribute that with a sane number of defaults. > > I'm not familiar with this, although it sounds like something that might > be > useful to add in future. Presumably this could be done by standardizing > names of "extras" and then having an option for easy_install (which then > would be configurable via the normal distutils config files). I'll keep > that in mind for 0.7. yes indeed is one of the most powerfull feature of emerge. the way it works on gentoo is as follows. there is a global config file (/etc/make.conf) that has all the global useflags the user has set then each package can set it's own set of useflags so when someone installs something the engine sets its global flags and then looks for package specific (package.use) and then for commandline flags, although commandline in gentoo is deprecated due to errors in stuff like package A I needs foo compile with bar support... anyway. I'll love to see something like this for setuptools this will make it easier to integrate into gentoo since one of the biggest problems right now with easy_install in gentoo is the lack of flexibility in the instalation. ohh I almost forgot a big part of emerge is build on python, so maybe even some code could be borrow.

1 0

Re: [Distutils] conditional external packages dependancies with setuptools
by Phillip J. Eby 24 Jun '06

24 Jun '06

At 01:29 PM 6/24/2006 -0400, Jorge Vargas wrote: >On 6/24/06, Phillip J. Eby ><<mailto:pje@telecommunity.com>pje(a)telecommunity.com> wrote: >>At 03:04 AM 6/24/2006 -0400, Jorge Vargas wrote: >> >but What I want to accomplish is having dependancies on some packages. for >> >example my project will have diferent database backends so I want to >> >depend on pysqlite or mysql-python depending on which the user wants as >> >his/her backend. I'm going to have lots of diferent backends, even some >> >that are not databases, so this will be a crutial thing for me or I'll end >> >up with very big dist files per release, which will mostly be waste if the >> >user never uses them. >> > >> >is something like this possible with setuptools now? >> >>Yes: >> >><http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras>http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras >> > >there it says that I can set them and then project depending on mine will >be able to add them to their install_required, but what I want is my >project to have it optional > >there is a reference that they can be pass as commands to easy_install but >can't find the switch at ><http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options>http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options If you have an optional feature called "bar" for your package named "foo", you would use: easy_install foo[bar] if there's also a "baz" feature and the user wants to install that too, they can use: easy_install foo[bar,baz] >I'm looking at something like the gentoo's USE flags system. where I can >have a script or config file that each install will use with the optional >packages they want, and distribute that with a sane number of defaults. I'm not familiar with this, although it sounds like something that might be useful to add in future. Presumably this could be done by standardizing names of "extras" and then having an option for easy_install (which then would be configurable via the normal distutils config files). I'll keep that in mind for 0.7.

1 0

Re: [Distutils] conditional external packages dependancies with setuptools
by Phillip J. Eby 24 Jun '06

24 Jun '06

At 03:04 AM 6/24/2006 -0400, Jorge Vargas wrote: >but What I want to accomplish is having dependancies on some packages. for >example my project will have diferent database backends so I want to >depend on pysqlite or mysql-python depending on which the user wants as >his/her backend. I'm going to have lots of diferent backends, even some >that are not databases, so this will be a crutial thing for me or I'll end >up with very big dist files per release, which will mostly be waste if the >user never uses them. > >is something like this possible with setuptools now? Yes: http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras

1 0

conditional external packages dependancies with setuptools
by Jorge Vargas 24 Jun '06

24 Jun '06

hi all I'm new to creating my own setuptools projects, although I have work with other people projects before, so I'm not that lost here. but What I want to accomplish is having dependancies on some packages. for example my project will have diferent database backends so I want to depend on pysqlite or mysql-python depending on which the user wants as his/her backend. I'm going to have lots of diferent backends, even some that are not databases, so this will be a crutial thing for me or I'll end up with very big dist files per release, which will mostly be waste if the user never uses them. is something like this possible with setuptools now? is it plan to be possible in the future? if so any estimates on when will this be?

1 0

Specification for package indexes?
by Jim Fulton 23 Jun '06

23 Jun '06

What form must an index take to be usable with setuptools? Is there anything documented how such a beast should be organized? What should it's pages should look like? Is there any special pattern setuptools (easy_install?) looks for to find pages with download links? Or does it search any link given? Also, I've noticed that if you gibe a location with find-links that has links to distributions for the thing you're looking for, it you can specify pretty much anything as an index. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 2

Is there any harm in clearing sys.path_importer_cache from time to time?
by Jim Fulton 23 Jun '06

23 Jun '06

I have a script based on setuptools that invokes easy install to check for and download newer distributions. I allow users to specify whether or not they want unzipped downloads. As a result, easy_install will sometimes replace a zip file with a directory or the other way around. This leads to problems in the invoking program because the sys.path_importer_cache is stale. Does anyone know if it is safe to clear the cache from time to time? If so, I'd be inclined to clear it any time I invoke easy_install. If it isn't safe, I'll probably just forego the feature of letting users force downloads to be unzipped, which I may do anyway to be safe. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 2

setuptools : easy_install error on berlios
by AGiss 23 Jun '06

23 Jun '06

berlios, sourceforge like, now use prdownloads system, like sourceforge. setuptools fail to find eggs, because it tries to download on "prdownload" which serves only html page with mirrors. package_index.py need a fix_berlios_url (or perhaps a more generic fix_forges_url with a list of translations) I'll have a look at the code, but I don't have much time thoses days. You can test with : easy_install pydirstat

2 5

Requirent specifiers specified? :)
by Jim Fulton 23 Jun '06

23 Jun '06

When specifying a dependencies and when asking for a package with easy_install, you can specify one or more specifiers. It's unclear what the rules are for combining specifiers. Imagine that I have a collection of eggs like: /home/jim/tmp/dist: used 92 available 41345796 -rw-rw-r-- 1 jim jim 671 Jun 19 17:43 demoneeded-1.0-py2.4.egg -rw-rw-r-- 1 jim jim 672 Jun 19 17:46 demoneeded-1.1-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.2-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.3-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.4-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.5-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.6-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.7-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.8-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.9-py2.4.egg Now, here are some examples of using the pkg_resources api to fetch a required distribution: >>> import pkg_resources >>> e = pkg_resources.Environment(['tmp/dist']) >>> ws = pkg_resources.WorkingSet() >>> ws.resolve([pkg_resources.Requirement.parse('demoneeded ==1.1, ==1.4')], e) [demoneeded 1.4 (/home/jim/tmp/dist/demoneeded-1.4-py2.4.egg)] Here, the specifiers were or-ed. OK. >>> ws.resolve([pkg_resources.Requirement.parse('demoneeded >1.1, <1.6')], e) [demoneeded 1.5 (/home/jim/tmp/dist/demoneeded-1.5-py2.4.egg)] Here they were and-ed. This makes sense, from a dwimy point of view. :) If they were or-ed, I'd expect to get 1.9. >>> ws.resolve([pkg_resources.Requirement.parse('demoneeded >1.1, <1.6, ==1.8')], e) [demoneeded 1.8 (/home/jim/tmp/dist/demoneeded-1.8-py2.4.egg)] Hm, here the ==1.8 seems to have been or-ed with the result of anding >1.1 and <1.6. >>> ws.resolve([pkg_resources.Requirement.parse('demoneeded <1.1, >1.6')], e) [demoneeded 1.9 (/home/jim/tmp/dist/demoneeded-1.9-py2.4.egg)] >>> ws.resolve([pkg_resources.Requirement.parse('demoneeded !=1.8, ==1.8')], e) [demoneeded 1.9 (/home/jim/tmp/dist/demoneeded-1.9-py2.4.egg)] I really don't know what's going on with these. :) Are the rules for combining specifiers specified anywhere? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 23

Optimizing easy-install upgrade
by Jim Fulton 22 Jun '06

22 Jun '06

Suppose I have the directory: /home/jim/tmp/dist: used 92 available 41345796 -rw-rw-r-- 1 jim jim 671 Jun 19 17:43 demoneeded-1.0-py2.4.egg -rw-rw-r-- 1 jim jim 672 Jun 19 17:46 demoneeded-1.1-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.2-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.3-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.4-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.5-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.6-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.7-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.8-py2.4.egg -rw-rw-r-- 1 jim jim 673 Jun 19 17:46 demoneeded-1.9-py2.4.egg and then run easy install telling it to install something I already have: [jim@ds9 ~]$ /usr/local/python/2.4/bin/easy_install -d tmp/dist -mxU demoneeded==1.1 Searching for demoneeded==1.1 Reading http://www.python.org/pypi/demoneeded/ Couldn't find index page for 'demoneeded' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://www.python.org/pypi/ Best match: demoneeded 1.1 Processing demoneeded-1.1-py2.4.egg Using /home/jim/tmp/dist/demoneeded-1.1-py2.4.egg Because this distribution was installed --multi-version, before you can import modules from this package in an application, you will need to 'import pkg_resources' and then use a 'require()' call similar to one of these examples, in order to select the desired version: pkg_resources.require("demoneeded") # latest installed version pkg_resources.require("demoneeded==1.1") # this exact version pkg_resources.require("demoneeded>=1.1") # this version or higher Note also that the installation directory must be on sys.path at runtime for this to work. (e.g. by being the application's script directory, by being on PYTHONPATH, or by being added to sys.path by your code.) Processing dependencies for demoneeded==1.1 Note that it looked at pypi even though it already had the only acceptable version. I'm not sure why it did this. Is this just a case of a missing optimization? Or is there some other reason for checking the index in a situation like this? I have some scripts that invoke easy_setup and I'd like to try to do some of this logic myself. Given a requirement, I'd like to get the specifiers and decide myself whether to invoke easy_install. I have 2 problems: - I don't want to parse the requirement myself, but, rather, use Requirement.parse. If I use Requirement.parse, I can use the specs attribute to get the specifiers, however, this attribute isn't documented. Should I assume that it is private? Or is it safe to use. - I'm still a bit foggy on how to interpret the specifiers. But we're discussing that in another thread. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 4

Puzzling easy_install behavior
by Jim Fulton 22 Jun '06

22 Jun '06

I'd like to share an experiment that I find puzzling and see if anyone could share some insight. Perhaps I'm doing something incorrectly. So, I have an links directory: [jim@ds9 tmp]$ ls links demo-1.0-py2.4.egg demoneeded-1.0-py2.4.egg index.html [jim@ds9 tmp]$ cat links/index.html <html><body> <a href="demo-1.0-py2.4.egg">demoneeded-1.0-py2.4.egg</a> <a href="demoneeded-1.0-py2.4.egg">demoneeded-1.0-py2.4.egg</a> </body></html> and an empty eggs directory: [jim@ds9 tmp]$ ls eggs Note that demo depends on demoneeded, without any qualifiers. I run easy_setup (0.6b3): [jim@ds9 tmp]$ /usr/local/python/2.4/bin/easy_install -q \ -f file:///home/jim/tmp/links/index.html -m -deggs demo and get the eggs I expect. [jim@ds9 tmp]$ ls eggs demo-1.0-py2.4.egg demoneeded-1.0-py2.4.egg I update the links with new versions of demo and demoneeded: [jim@ds9 tmp]$ ls links demo-1.0-py2.4.egg demoneeded-1.0-py2.4.egg index.html demo-1.1-py2.4.egg demoneeded-1.1-py2.4.egg [jim@ds9 tmp]$ cat links/index.html <html><body> <a href="demo-1.0-py2.4.egg">demoneeded-1.0-py2.4.egg</a> <a href="demoneeded-1.0-py2.4.egg">demoneeded-1.0-py2.4.egg</a> <a href="demo-1.1-py2.4.egg">demoneeded-1.1-py2.4.egg</a> <a href="demoneeded-1.1-py2.4.egg">demoneeded-1.1-py2.4.egg</a> </body></html> I haven't changed the unqualified dependence on demoneeded. Now I rerun easy_install: [jim@ds9 tmp]$ /usr/local/python/2.4/bin/easy_install -q \ -f file:///home/jim/tmp/links/index.html -m -deggs demo and I get a new demo egg even though I didn't elect to upgrade: [jim@ds9 tmp]$ ls eggs demo-1.0-py2.4.egg demo-1.1-py2.4.egg demoneeded-1.0-py2.4.egg I find this a bit mysterious. I thought easy_install wouldn't search the find links and index if existing distributions meet a requirement unless --upgrade was used. Is special consideration given to file URLs? (If so, this makes test writing a bit more challenging.) If I supply the upgrade option, I get: [jim@ds9 tmp]$ /usr/local/python/2.4/bin/easy_install -q \ -f file:///home/jim/tmp/links/index.html -m -U - deggs demo Couldn't find index page for 'demo' (maybe misspelled?) Scanning index of all packages (this may take a while) [jim@ds9 tmp]$ ls eggs demo-1.0-py2.4.egg demo-1.1-py2.4.egg demoneeded-1.0-py2.4.egg So when I said upgrade, the index was checked, but when I installed the distributions initially, it wasn't. Why? Why is upgrade handled differently from an initial install. Also, it's a bit surprising that I didn't get the available upgrade for demoneeded. Is that intended? Are there plans for a recursive upgrade option? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 3

Re: [Distutils] Infinite easy_install loop for mathdom==0.7.1
by Phillip J. Eby 21 Jun '06

21 Jun '06

At 12:31 AM 6/22/2006 +0200, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >Sorry for flooding the list with my questions, but I think I found >another problem with easy_install. Calling it on "mathdom==0.7.1" >invokes an infinite sourceforge download loop. I've given up after >watching "Download failed" messages for about 20 minutes. So I can't >prove this loop is infinite. ;-) The problem is the broken URL for mathdom 0.7.1 provided on the mathdom PyPI page. Sourceforge has no such file. Please let the author know about the problem. In the meantime: easy_install http://cheeseshop.python.org/packages/source/m/mathdom/mathdom-0.7.1.tar.gz should get you the package that is available. (It's not using the 2.4 egg because again, you're on Python 2.3.) >BTW, is there any kind of tracker for setuptools, so I could use that >instead of writing directly to this list? No; the intent is to allow everyone to learn from the answers, and thus better support others. This wouldn't happen as well with a walled-off tracker.

1 0

Re: [Distutils] easy_install download logic?
by Phillip J. Eby 21 Jun '06

21 Jun '06

At 11:02 PM 6/21/2006 +0200, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >Hi, > >I'm wondering how exactly easy_install looks up packages on PyPI. >Right now I'm looking at two specific packages: moofx and SQLObject. >Both have "Home page" link and both have eggs distributions listen on >PyPI. The only difference is that moofx has also a "Download URL", >which seems to be bad. > >When I do "easy_install SQLObject" it looks at PyPI, then link from >"Home page" field and fall backs to egg: > >===== >$ sudo easy_install SQLObject==0.7.0 >Searching for SQLObject==0.7.0 >Reading http://www.python.org/pypi/SQLObject/ >Reading http://sqlobject.org >Best match: SQLObject 0.7.0 >Downloading >http://cheeseshop.python.org/packages/2.3/S/SQLObject/SQLObject-0.7.0-py2.3… >===== > >But this doesn't happen for moofx. Actually, it does. Notice that you're using Python 2.3 -- moofx only has a Python 2.4 egg uploaded, and no source distro or 2.3 egg. >It looks at PyPI, then at "Home >page", then at "Download URL" and fails, ignoring eggs that are there: Because the egg is for 2.4, and you're using 2.3. >Having broken download URL is a bad thing, but shouldn't easy_install >use eggs when they're available? easy_install builds a complete index of the eggs or other downloadable distributions it finds, and then chooses the "best" one. >And why search "Homepage" and >"Download URL" links when eggs are already on PyPI? To ensure that you can request the latest version; sometimes packagers don't update their PyPI pages as often.

1 0

Infinite easy_install loop for mathdom==0.7.1
by Michał Kwiatkowski 21 Jun '06

21 Jun '06

Sorry for flooding the list with my questions, but I think I found another problem with easy_install. Calling it on "mathdom==0.7.1" invokes an infinite sourceforge download loop. I've given up after watching "Download failed" messages for about 20 minutes. So I can't prove this loop is infinite. ;-) BTW, is there any kind of tracker for setuptools, so I could use that instead of writing directly to this list? I couldn't found one one the homepage. mk -- . o . >> http://joker.linuxstuff.pl << . . o It's easier to get forgiveness for being wrong o o o than forgiveness for being right.

1 0

easy_install download logic?
by Michał Kwiatkowski 21 Jun '06

21 Jun '06

Hi, I'm wondering how exactly easy_install looks up packages on PyPI. Right now I'm looking at two specific packages: moofx and SQLObject. Both have "Home page" link and both have eggs distributions listen on PyPI. The only difference is that moofx has also a "Download URL", which seems to be bad. When I do "easy_install SQLObject" it looks at PyPI, then link from "Home page" field and fall backs to egg: ===== $ sudo easy_install SQLObject==0.7.0 Searching for SQLObject==0.7.0 Reading http://www.python.org/pypi/SQLObject/ Reading http://sqlobject.org Best match: SQLObject 0.7.0 Downloading http://cheeseshop.python.org/packages/2.3/S/SQLObject/SQLObject-0.7.0-py2.3… ===== But this doesn't happen for moofx. It looks at PyPI, then at "Home page", then at "Download URL" and fails, ignoring eggs that are there: ===== $ sudo easy_install moofx Searching for moofx Reading http://www.python.org/pypi/moofx/ Reading http://moofx.mad4milk.net/ Reading http://www.turbogears.org/cogbin/ No local packages or download links found for moofx error: Could not find suitable distribution for Requirement.parse('moofx') ===== Having broken download URL is a bad thing, but shouldn't easy_install use eggs when they're available? And why search "Homepage" and "Download URL" links when eggs are already on PyPI? Thanks for any help, mk -- . o . >> http://joker.linuxstuff.pl << . . o It's easier to get forgiveness for being wrong o o o than forgiveness for being right.

1 0

Re: [Distutils] easy_install fails for Amara XML Toolkit
by Phillip J. Eby 20 Jun '06

20 Jun '06

At 10:58 PM 6/20/2006 +0200, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: >easy_install from setuptools 0.6b3 fails when trying to download Amara >XML Toolkit from PyPI. Full backtrace in attachement. It appears that ftp:// URLs opened by urllib2 don't get any content-type information. I'll fix this in the next release. In the meantime, if you change this line: File "/usr/lib/python2.3/site-packages/setuptools-0.6b3-py2.3.egg/setuptools/package_index.py", line 165, in process_url if 'html' not in f.headers['content-type'].lower(): to read instead: if 'html' not in f.headers.get('content-type', '').lower(): that should get you out of trouble till then. Thanks.

1 0

easy_install fails for Amara XML Toolkit
by Michał Kwiatkowski 20 Jun '06

20 Jun '06

Hi, easy_install from setuptools 0.6b3 fails when trying to download Amara XML Toolkit from PyPI. Full backtrace in attachement. mk -- . o . >> http://joker.linuxstuff.pl << . . o It's easier to get forgiveness for being wrong o o o than forgiveness for being right.

1 0

[Announce] stdeb - Python to Debian source package conversion utility
by Andrew Straw 19 Jun '06

19 Jun '06

I would like to announce the initial public release of stdeb, which may be found at http://stdeb.python-hosting.com/ . The rest of this email is copied directly from that web-page. stdeb - Python to Debian source package conversion utility ========================================================== stdeb_ ("setuptools debian") produces Debian source packages from Python packages via a new distutils command, ``sdist_dsc``, which produces a Debian source package of a Python package. Automatic defaults are provided for the Debian package, but many aspects of the resulting package can be customized via a configuration file. .. _stdeb: http://stdeb.python-hosting.com/ News ---- 2006-06-19: Version 0.1 Released. See the `download page`_. Invocation ---------- All methods eventually result in a call to the ``sdist_dsc`` distutils command. You may prefer to do so directly:: python -c "import stdeb; execfile('setup.py')" sdist_dsc Alternatively, two scripts are provided:: stdeb_run_setup [options] # calls "python setup.py sdist_dsc [options]" py2dsc [options] mypackage-0.1.tar.gz # uses pre-built Python source package In all cases, a Debian source package is produced from unmodified Python packages. The following files are produced: * ``packagename_versionname.orig.tar.gz`` * ``packagename_versionname-debianversion.dsc`` * ``packagename_versionname-debianversion.diff.gz`` These can then be compiled into binary packages using the standard Debian machinery (e.g. dpkg-buildpackage). Download -------- Files are available at the `download page`_. .. _download page: http://stdeb.python-hosting.com/wiki/Download The subversion repository is available at https://svn.stdeb.python-hosting.com/trunk Background ---------- For the average Python package, its source distribution (python_package.tar.gz created with ``python setup.py sdist``) contains nearly everything necessary to make a Debian source package. This near-equivalence encouraged me to write this little distutils extension, which executes the setup.py file to extract relevant information. This process is made significantly easier through the use of setuptools_. .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools setuptools is used because of the opportunities it provides, although many of these features are currently un(der)-utilized. For example, setuptools could make the job of "Debianizing" python console and gui scripts much easier. I wrote this initially to Debianize several Python packages of my own, but I have the feeling it could be generally useful. It appears similar, at least in theory, to easydeb_ and `Logilab's Devtools`_. .. _easydeb: http://easy-deb.sourceforge.net/ .. _Logilab's DevTools: http://www.logilab.org/projects/devtools Prerequisites ------------- * Python_ 2.3 or greater * setuptools_ * subprocess.py_ (included with Python 2.4, backwards compatible with Python 2.3) .. _Python: http://www.python.org/ .. _subprocess.py: http://svn.python.org/view/python/trunk/Lib/subprocess.py?rev=46651&view=log Customizing the produced Debian source package ---------------------------------------------- stdeb will attempt to provide reasonable defaults, but these are only guesses. To customize the Debian source package produced, you may write config files of the format understood by ConfigParser_. When building each package, stdeb looks for the existance of a ``stdeb.cfg`` file in the ``.egg-info`` directory. You may specify an additional config file with the command-line option --extra-cfg-file. .. _ConfigParser: http://docs.python.org/lib/module-ConfigParser.html Here's an example .cfg file which builds several packages:: [DEFAULT] Debian-Version: 0ads1 [setuptools] Source: python-setuptools [numpy] Source: python-numpy Upstream-Version-Prefix: 0.9.8+ Build-Depends: python-dev, refblas3-dev, lapack3-dev Build-Conflicts: atlas3-base, atlas3-base-dev [matplotlib] # matplotlib doesn't incorporate its SVN version number into sdist-built tarballs. # Therefore, if building the SVN version, substitute the version into the # "Upstream-Version-Suffix" variable and use py2dsc. # (For some reason, "debuild -sa" won't build matplotlib because tk.h isn't found.) Source: python-matplotlib Upstream-Version-Suffix: .dev2500 Build-Depends: python-dev, python-numpy, python-numarray, python-numeric, python-gtk2-dev, tk8.4-dev, libwxgtk2.4-dev Depends: python-gtk2, python-numpy, python-numeric, python-numarray Suggests: gs-gpl [scipy] Source: python-scipy Upstream-Version-Prefix: 0.4.9+ Build-Depends: python-numpy Depends: python-numpy .. _numpy: http://scipy.org/NumPy Using stdeb on stdeb -------------------- There is a chicken-and-egg problem when trying to make a Debian package of stdeb with stdeb. Here's a recipe to avoid it:: # in the stdeb distribution directory (with setup.py) python setup.py sdist python setup.py build PYTHONPATH="build/lib" python stdeb/py2dsc.py dist/stdeb-VERSION.tar.gz TODO ---- * Make output meet `Debian Python Policy`_ specifications or the `new python policy`_. This will include several things, including: - the ability to make custom changelogs - the ability to patch upstream source - the ability to include project-supplied documentation (including license information) as a -doc package - the ability to include project-supplied examples, tests, and data as a separate package - much more not listed * Support python-central_ and/or python-support. * Create (better) documentation * Log output using standard distutils mechanisms * Allow distribution-specific configuration parameters (e.g. numpy-dapper) .. _debian python policy: http://www.debian.org/doc/packaging-manuals/python-policy/ .. _new python policy: http://wiki.debian.org/DebianPython/NewPolicy .. _python-central: http://python-modules.alioth.debian.org/python-central_howto.txt Call for volunteers ------------------- I don't have a lot of time for this. This project stands a very real chance of being only a shadow of its potential self unless people step up and contribute. There are numerous ways in which people could help. In particular, I'd be interested in finding a co-maintainer or maintainer if the project generates any interest. Secondarily, I would appreciate advice from Debian developers or Ubuntu MOTUs about the arcane details of Python packaging. License ------- MIT-style license. Copyright (c) 2006 stdeb authors. See the LICENSE.txt file provided with the source distribution for full details. Authors ------- Andrew Straw, California Institute of Technology <strawman(a)astraw.com>

1 0

Re: [Distutils] setuptools: mishandles install of non-python scripts
by Phillip J. Eby 15 Jun '06

15 Jun '06

At 12:52 PM 6/12/2006 -0400, Phillip J. Eby wrote: >At 05:22 PM 6/9/2006 -0700, Ned Deily wrote: > >In build_scripts.py in distutils.command, distuitils uses the results of > >first_line_re to decide whether to adjust the python value in the shbang > >line of the script: if no "python" is found, distutils installs the > >script without modification. easy_install.py uses the first_line_re > >test from distutils but seems to unconditionally add a wrapper to the > >script during installation regardless of the script's type. > >Who needs shell scripts when you have Python? ;) > >I can (sort of) fix this, but there are some potentially-significant >limitations. There's another wrinkle, as it turns out. It's not sufficient to inspect the first line for a #!python presence - it's perfectly valid and possible to have .py or .pyw scripts that don't have a #! line, especially on Windows. So, the actual condition to test if the program is a Python script should be to compile it. If it's valid Python syntax, easy_install will assume it's a Python script, rather than a shell, batch, or other kind of script file. But, it's *also* necessary to check whether there is a *non*-Python #! line, if the first line begins with #!. It's quite possible for a shell script to be syntactically valid Python, especially if you have a shell prolog hidden in what looks like a Python docstring. This is a trick that I believe is listed in the Python FAQ, although I don't know if it's used in any currently-distributed scripts. But it should be supported. So the full rules for analyzing scripts should be: * If there's a #! line, use first_line_re to tell if it's Python * If there's a '.py' or '.pyw' extension, assume it's Python * Otherwise, try to compile the script. If it compiles, assume it's Python * Otherwise, assume it's not. There is one possiblity I'm leaving out here, which is that you have some other script interpreter (e.g. .bat or .cmd files on Windows) that just magically happen to be syntactically-valid Python. In the .bat/.cmd case, anything more complex than a series of one-word commands with no arguments would fail to be valid Python, so it seems incredibly unlikely that this would ever happen. Actually, there's one other possibility I'm also leaving out, which is that you have a .bat or .cmd or some other script whose first line uses -x to skip that line. In such a case, lines 2-N of the file are valid Python, but line 1 doesn't start with #!. In theory, what this should do is keep the first line and wrap the rest. However, such scripts aren't supported by the distutils, so I'm not going to add them to setuptools for 0.6.

1 0

setuptools: mishandles install of non-python scripts
by Ned Deily 15 Jun '06

15 Jun '06

easy_install doesn't properly handle non-python scripts in a distribution. The problem shows up when using easy_install to install mercurial: <http://cheeseshop.python.org/pypi/Mercurial/> The mercurial distribution includes two scripts, one a python script, the other a shell script: hg - #!/usr/bin/env python hgmerge - #!/bin/sh Using easy_install, both scripts get installed with a python wrapper script. Execution of hgmerge fails when the wrapper tries to run the shell script under python: $ hgmerge Traceback (most recent call last): File "/usr/local/python/bin/hgmerge", line 5, in ? pkg_resources.run_script('mercurial==dbeaa4369121', 'hgmerge') File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-pac kages/setuptools-0.6b3-py2.4.egg/pkg_resources.py", line 407, in run_script self.require(requires)[0].run_script(script_name, ns) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-pac kages/setuptools-0.6b3-py2.4.egg/pkg_resources.py", line 1084, in run_script execfile(script_filename, namespace, namespace) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-pac kages/mercurial-dbeaa4369121-py2.4-macosx-10.4-fat.egg/EGG-INFO/scripts/h gmerge", line 20 if [ -z "$EDITOR" ]; then ^ SyntaxError: invalid syntax If mercurial is installed using distutils directly; python setup.py install both scripts work properly. In build_scripts.py in distutils.command, distuitils uses the results of first_line_re to decide whether to adjust the python value in the shbang line of the script: if no "python" is found, distutils installs the script without modification. easy_install.py uses the first_line_re test from distutils but seems to unconditionally add a wrapper to the script during installation regardless of the script's type. -- Ned Deily, nad(a)acm.org

2 2

Re: [Distutils] Minor bug in PythonEggs setuptools-0.6b3 and earlier)?!
by Phillip J. Eby 14 Jun '06

14 Jun '06

At 12:11 PM 6/14/2006 +0200, Jens Engel wrote: >Hello, > >PythonEggs seem to have a problem access the docstring of the root package. >Note that there is no problem accessing docstrings of contained modules >and packages with Python's help(). The pydoc module (which implements the help() function) doesn't support zip files when listing the contents of a package. (That is, it's not the docstring that there's a problem with, it's help() trying to list the modules from the package.) This is a Python bug that is fixed in Python 2.5. I plan to release a hotfix package for older versions of Python that fixes the bug. In the meantime, you can work around it by using the --always-unzip option when easy_install-ing a package; the package will then be installed as a directory instead of a zipfile. But be sure you need it, because egg directories slow down startup and importing much more than zipfiles do. Alternatively, you can just grab the Python 2.5 version of the pydoc and pkgutil modules and drop them on your PYTHONPATH ahead of the standard library versions. (The 2.5 version of pydoc uses utilities in pkgutil to access packages' module lists.)

1 0

Minor bug in PythonEggs setuptools-0.6b3 and earlier)?!
by Jens Engel 14 Jun '06

14 Jun '06

Hello, PythonEggs seem to have a problem access the docstring of the root package. Note that there is no problem accessing docstrings of contained modules and packages with Python's help(). The following session gives an example what I mean by using (and installing) the funkload package. SYNDROME: Install PythonEgg and verify that help() does no longer work => SYNDROME shell> cd funkload-1.5.0 shell> python setup.py install ... # -- INSTALLS PythonEgg ... # TEST: To access docstring of egg-root package -> FAILS. shell> cd .. shell> python >>> import funkload >>> help(funkload) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/site-packages/setuptools-0.6b3-py2.4.egg/site.py", line 328, in __call__ File "/usr/lib/python2.4/pydoc.py", line 1647, in __call__ self.help(request) File "/usr/lib/python2.4/pydoc.py", line 1691, in help else: doc(request, 'Help on %s:') File "/usr/lib/python2.4/pydoc.py", line 1475, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/usr/lib/python2.4/pydoc.py", line 295, in document if inspect.ismodule(object): return self.docmodule(*args) File "/usr/lib/python2.4/pydoc.py", line 1052, in docmodule for file in os.listdir(object.__path__[0]): OSError: [Errno 2] No such file or directory: '/usr/lib/python2.4/site-packages/funkload-1.5.0-py2.4.egg/funkload' Ciao, Jens Engel

1 0

bad files extensions of text digests in list archive
by Jérôme Bouat 12 Jun '06

12 Jun '06

I browsed the list archive in: http://mail.python.org/pipermail/distutils-sig/ Some text links are tagged as *.txt.gz but there are simply plain text.

2 2

unrecognised swig options ?
by Risky Martin 10 Jun '06

10 Jun '06

Hi, I am trying to use disutils's features with 'SWIG'... but hit a rather strange problem. To reproduce it: setup.py ------------------------------------------------------ from distutils.core import setup, Extension e = Extension("_foo", sources = ["foo.i", ], swig_opts = ["-outdir .", ]) setup(name="foo", ext_modules=[e, ]) ------------------------------------------------------- building fails like: > python setup.py build running build running build_ext building '_foo' extension swigging foo.i to foo_wrap.c swig -python -outdir . -o foo_wrap.c foo.i swig error : Unrecognized option -outdir . Use 'swig -help' for available options. error: command 'swig' failed with exit status 1 but a copy/paste of the swig command shows that '-outdir' *is* recognised... > swig -python -outdir . -o foo_wrap.c foo.i Unable to find file 'foo.i'. Are the permitted options for SWIG hardcoded in 'distutils' ? RiMa

1 1

setuptools 0.6b3 released
by Phillip J. Eby 09 Jun '06

09 Jun '06

This is a bugfix release, to fix problems found by Jim Fulton, Markku Mielityinen, Nathan Yergler, and others in 0.6b2 or earlier versions.

1 0

error: None
by Nathan R. Yergler 09 Jun '06

09 Jun '06

Thanks to Phillip for the insight into the interaction between command-line arguments and options. So another question regarding error reporting. When I so something like: $ PYTHONPATH=lib/ python ez_setup.py --install-dir lib/ --script-dir bin/ --site-dirs lib/ zope.testing setuptools is bootstrapped correctly, and zope.testing and its dependencies are downloaded and installed. However, at the end of the run you get a message like: Installed /home/nathan/Projects/zope.i18n/lib/setuptools-0.6b1-py2.4.egg Processing dependencies for setuptools==0.6b1 error: None Does anyone have any insights into this? From the output it looks like it's processing the zope.testing and zope.testing dependencies first, then setuptools. Even with the error, everything seems to be installed correctly; I can just see how the message would be disconcerting to some users. Thanks again, Nathan

2 1

Bug in setuptools-0.6a11-py2.4 ?
by Uche Ogbuji 08 Jun '06

08 Jun '06

I'm trying to port 4Suite and Amara to setuptools. I thought 4Suite would be the hard part, but I have it basically functioning now. No such luck with Amara, though. I can't get setuptools to handle the fact that Amara has all its code in a subdir named lib, such that it used to work fine in plain distutils as follows: setup(package_dir = {'amara': 'lib'}, packages = ['amara'],...) This same invocation with setuptools does not give an error message, but no packages are found or processed. I also tried: setup(package_dir = {'amara': 'lib'}, packages = find_packages(), setup(package_dir = {'amara': 'lib'}, packages = find_packages('lib'), setup(package_dir = {'amara': 'lib'}, packages = find_packages(), packages = ['amara'], and many other desperate attempts, with no luck. It feels to me like a bug in setuptools with such a layout, but I'm really surprised, because it's so common, and even covered explicitly by the distutils and setuptools docs. If anyone else wants to try you can do so as follows: cvs -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot login cvs -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot get 4Suite -r EASYINSTALL-branch cvs -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot get Amara This CVS is also accessible via viewcvs: http://cvs.4suite.org/viewcvs/ I'd appreciate any help. One last thing: is there an issue tracker for setuptools? -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Articles: http://uche.ogbuji.net/tech/publications/

2 3

Bug in easy_install?
by Jim Fulton 06 Jun '06

06 Jun '06

If I give easy_install - an ordinary spec (e.g. "demo") - an -f option that points to a local directory containing a bunch of eggs and that is not on sys,path, - ask it to install to some directory (-d), and - use the -m option it doesn't copy eggs found to the install directory even though the source directory isn't on sys.path. The logic for deciding whether to copy seems to be: # Installation is also needed if file in tmpdir or is not an egg install_needed = install_needed or os.path.dirname(download) == tmpdir install_needed = install_needed or not download.endswith ('.egg') where install_needed starts out as false in this case because the spec is not a url. The second part has no effect because the value if the download variable ends in .egg. The --always-copy documentation hints that distributions will be copied unless they are found in a directory sys.path, but I see no check. Why are the eggs not copied? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1

setuptools & python2.5
by Ronald Oussoren 06 Jun '06

06 Jun '06

Hi, I tried to install setuptools 0.6b2 in my python2.5 installation, but that doesn't seem to work. The ez_setup.py installation method doesn't work because there is no egg for python2.5, therefore I downloaded the sources and ran 'python2.5 setup.py install'. This results in this following output at the bottom of this message. It looks like python2.5 & setuptools don't mix very well at the moment. Ronald setuptools-0.6b2 ronald$ python2.5 setup.py install /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ distutils/dist.py:263: UserWarning: Unknown distribution option: 'entry_points' warnings.warn(msg) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ distutils/dist.py:263: UserWarning: Unknown distribution option: 'zip_safe' warnings.warn(msg) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ distutils/dist.py:263: UserWarning: Unknown distribution option: 'test_suite' warnings.warn(msg) running install running build running build_py creating build creating build/lib copying pkg_resources.py -> build/lib copying easy_install.py -> build/lib copying site.py -> build/lib creating build/lib/setuptools copying setuptools/__init__.py -> build/lib/setuptools copying setuptools/archive_util.py -> build/lib/setuptools copying setuptools/depends.py -> build/lib/setuptools copying setuptools/dist.py -> build/lib/setuptools copying setuptools/extension.py -> build/lib/setuptools copying setuptools/package_index.py -> build/lib/setuptools copying setuptools/sandbox.py -> build/lib/setuptools creating build/lib/setuptools/command copying setuptools/command/__init__.py -> build/lib/setuptools/command copying setuptools/command/alias.py -> build/lib/setuptools/command copying setuptools/command/bdist_egg.py -> build/lib/setuptools/command copying setuptools/command/bdist_rpm.py -> build/lib/setuptools/command copying setuptools/command/build_ext.py -> build/lib/setuptools/command copying setuptools/command/build_py.py -> build/lib/setuptools/command copying setuptools/command/develop.py -> build/lib/setuptools/command copying setuptools/command/easy_install.py -> build/lib/setuptools/ command copying setuptools/command/egg_info.py -> build/lib/setuptools/command copying setuptools/command/install.py -> build/lib/setuptools/command copying setuptools/command/install_egg_info.py -> build/lib/ setuptools/command copying setuptools/command/install_lib.py -> build/lib/setuptools/ command copying setuptools/command/install_scripts.py -> build/lib/setuptools/ command copying setuptools/command/rotate.py -> build/lib/setuptools/command copying setuptools/command/saveopts.py -> build/lib/setuptools/command copying setuptools/command/sdist.py -> build/lib/setuptools/command copying setuptools/command/setopt.py -> build/lib/setuptools/command copying setuptools/command/test.py -> build/lib/setuptools/command copying setuptools/command/upload.py -> build/lib/setuptools/command creating build/lib/setuptools/tests copying setuptools/tests/__init__.py -> build/lib/setuptools/tests copying setuptools/tests/doctest.py -> build/lib/setuptools/tests copying setuptools/tests/test_resources.py -> build/lib/setuptools/tests copying setuptools/cli.exe -> build/lib/setuptools copying setuptools/gui.exe -> build/lib/setuptools running build_scripts creating build/scripts-2.5 copying and adjusting easy_install.py -> build/scripts-2.5 changing mode of build/scripts-2.5/easy_install.py from 644 to 755 running install_lib running install_scripts copying build/scripts-2.5/easy_install.py -> /Library/Frameworks/ Python.framework/Versions/2.5/bin changing mode of /Library/Frameworks/Python.framework/Versions/2.5/ bin/easy_install.py to 755 running install_egg_info Removing /Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6b2-py2.5.egg-info Writing /Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6b2-py2.5.egg-info

2 1

setuptools 0.6b2 released
by Phillip J. Eby 01 Jun '06

01 Jun '06

This is a bugfix release to fix a few issues with 0.6b1. Please upgrade and test if you can, I'd like to release an 0.6 final soon. There are still a couple of known minor issues that I haven't addressed yet (error messages from ez_setup/easy_isntall reported here by Nathan Yergler), but I wanted to get this intermediate release out because of one serious bug that affects you if you install a package whose name begins with the word "import" on Windows -- e.g., my own "Importing" package, published recently on PyPI. Anyway, the next release of 0.6 should be a release candidate, so please beat on this one hard to find any remaining bugs. I'd like to get started on 0.7 (and the "nest" tool suite) as soon as practical. (By the way: setuptools 0.6 is probably not going in the 2.5 stdlib; after lots of discussion on Python-Dev, it's fairly clear that some 0.7 release should be the earliest version to go in, once the "nest" tools are done. Practically speaking, that probably means waiting until Python 2.6, due to the lead time that would be needed to get adequate field testing of the "nest" tools once they're written.)

3 4