Mailman 3 August 2007 - Distutils-SIG

Upgrading dependencies
by Charlie Moad April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

-----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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

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 April 29, 2018

April 29, 2018

3 2

eggs and Python Unicode variants (UCS2, UCS4)
by Martijn Faassen May 29, 2009

May 29, 2009

Hi there, In the lxml project (http://codespeak.net/lxml), we've just noticed the following problem with lxml eggs: you can easy_install an egg that won't work for your Python. This is because Python can be compiled with either 2 or 4 bytes unicode as its internal representation. Any egg that contains compiled C code that uses unicode such as lxml will run into trouble: if it's compiled with a 4 bytes unicode Python, it won't work on a 2 bytes unicode Python, and vice versa. This problem is fairly common in Linux. Many distributions such as Ubuntu and Fedora compile their python with 4 bytes unicode internal representation. If you compile a Python interpreter by hand it defaults to 2 bytes unicode, however. Hand-building a Python interpreter is done fairly commonly by Linux sysadmins for various reasons. It would therefore be very nice if it became possible to make eggs for the different unicode compilation options of Python. This configuration dimension is a real world issue for any binary Python module that does anything with unicode text.. In an earlier mail to this list: http://mail.python.org/pipermail/distutils-sig/2005-October/005222.html M.-A. Lemburg and Phillip Eby had the following discussion: [MAL] >>Please make sure that your eggs catch all possible >>Python binary build dimensions: >> >>* Python version >>* Python Unicode variant (UCS2, UCS4) >>* OS name >>* OS version >>* Platform architecture (e.g. 32-bit vs. 64-bit) [PJE] >As far as I know, all of this except the Unicode variant is captured in >distutils' get_platform(). And if it's not, it should be, since it >affects any other kind of bdist mechanism. I'm not sure whether this means this needs to be escalated from setuptools to the Python interpreter level itself. With this mail, I've done the job escalating this lxml problem to what appears to be the right place, though. :) Thanks, Martijn

5 5

unicode bug in distutils
by Tarek Ziadé April 4, 2009

April 4, 2009

Hello, I have created a setup.py file for distirbution and I bumped into a small bug when i tried to set my name in the contact field (Tarek Ziadé) Using string (utf8 file): setup( maintainer="Tarek Ziadé" ) leads to: File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 162, in send_metadata auth) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/command/register.py", line 257, in post_to_server value = unicode(value).encode("utf-8") UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 10: ordinal not in range(128) Using unicode: setup( maintainer=u"Tarek Ziadé" ) leads to: File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py", line 1094, in write_pkg_file file.write('Author: %s\n' % self.get_contact() ) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 18: ordinal not in range(128) I would propose a patch for this problem but i don't know what would be the best input (i guess unicode for names) Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

6 9

Adventures with x64, VS7 and VS8 on Windows
by Mark Hammond March 21, 2008

March 21, 2008

Hi all, I hope the cross-post is appropriate. I've started playing with getting the pywin32 extensions building under the AMD64 architecture. I started building with Visual Studio 8 (it was what I had handy) and I struck a few issues relating to the compiler version that I thought worth sharing. * In trying to build x64 from a 32bit VS7 (ie, cross-compiling via the PCBuild directory), the python.exe project fails with: pythoncore fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'AMD64' is this a known issue, or am I doing something wrong? * The PCBuild8 project files appear to work without modification (I only tried native compilation here though, not a cross-compile) - however, unlike the PCBuild directory, they place all binaries in a 'PCBuild8/x64' directory. While this means that its possible to build for multiple architectures from the same source tree, it makes life harder for tools like 'distutils' - eg, distutils already knows about the 'PCBuild' directory, but it knows nothing about either PCBuild8 or PCBuild8/x64. A number of other build processes also know to look inside a PCBuild directory (eg, Mozilla), so instead of formalizing PCBuild8, I think we should merge PCBuild8 into PCBuild. This could mean PCBuild/vs7 and PCBuild/vs8 directories with the "project" files, but binaries would still be generated in the 'PCBuild' (or PCBuild/x64) directory. This would mean the same tree isn't capable of hosting 2 builds from different VS compilers, but I think that is reasonable (if it's a problem, just have multiple source directories). I understand that PCBuild8 is not "official", but in the assumption that future versions of Python will use a compiler later than VS7, it makes sense to me to clean this up now - what are others opinions on this? * Re the x64 directory used by the PCBuild8 process. IMO, it makes sense to generate x64 binaries to their own directory - my expectation is that cross-compiling between platforms is a reasonable use-case, and we should support multiple achitectures for the same compiler version. This would mean formalizing the x64 directory in both 'PCBuild' and distutils, and leaving other external build processes to update as they support x64 builds. Does this make sense? Would this fatally break other scripts used for packaging (eg, the MSI framework)? * Wide characters in VS8: PC/pyconfig.h defines PY_UNICODE_TYPE as 'unsigned short', which corresponds with both 'WCHAR' and 'wchar' in previous compiler versions. VS8 defines this as wchar_t, which I'm struggling to find a formal definition for beyond being 2 bytes. My problem is that code which assumes a 'Py_UNICODE *' could be used in place of a 'WCHAR *' now fails. I believe the intent on Windows has always been "PyUNICODE == 'native unicode'" - should PC/pyconfig.h reflect this (ie, should pyconfig.h grow a version specific definition of PyUNICODE as wchar_t)? * Finally, as something from left-field which may well take 12 months or more to pull off - but would there be any interest to moving the Windows build process to a cygwin environment based on the existing autoconf scripts? I know a couple of projects are doing this successfully, including Mozilla, so it has precendent. It does impose a greater burden on people trying to build on Windows, but I'd suggest that in recent times, many people who are likely to want to build Python on Windows are already likely to have a cygwin environment. Simpler mingw builds and nuking MSVC specific build stuff are among the advantages this would bring. It is not worth adding this as "yet another windows build option" - so IMO it is only worth progressing with if it became the "blessed" build process for windows - if there is support for this, I'll work on it as the opportunity presents itself... I'm (obviously) only suggesting we do this on the trunk and am happy to make all agreed changes - but I welcome all suggestions or critisisms of this endeavour... Cheers, Mark

14 66

bdist_wininst and Vista User Account Control (UAC)
by Mark Hammond March 10, 2008

March 10, 2008

The pywin32 extensions require (well, prefer) administrative access during installation - certain files are copied to the System32 directory and the registry at HKEY_LOCAL_MACHINE is written to. Also, if I understand correctly, if Python happened to be installed into "\Program Files", admin access would be required to create any files in that directory tree - I'm not sure what permissions the \PythonXX directory are created with, but its not unreasable to assume that some shops might choose to secure that directory similarly to "\Program Files". The simplest way to achieve this for bdist_wininst installations is to include some magic in a "manifest". I've confirmed that once this magic is added, programs created by bdist_wininst get the little "shield" icon overlay and prompt for elevation before starting the executable. A problem here is that not all installations will require admin access - eg, a user who installed Python just for themselves will not need elevation to install an extension. A solution here would be for the installer to *not* be marked as requiring elevation, then sniffing the registry to make an educated guess (eg, HKLM\Software\Python\PythonCore\2.5 existing could indicate admin access is required). If it finds elevation is required, it would spawn another copy of itself with elevation requested, and terminate. This will have a side-effect of meaning the installer never gets the "shield" overlay, meaning the user will not be expecting to be prompted - but that is something we can live with. However, there is a complication here. Any "pure python" packages are not tied to a particular Python version, so the user can choose what installed Python version to use. Hence, in the general case, we can only determine if admin is required after the UI has opened and the user has selected the Python version. Arranging for the new "elevated" child process at this point will be (a) ugly, as the UI will vanish before the child process displays its GUI and (b) would require additional command-line processing logic - ie, passing the target directory to the child process. If we could make the determination *before* the GUI opens, it would appear seamless and would not require special command-line handling (the child process just does everything) So I see a few alternatives, but none are very desirable: * Only make this "admin required" check if a specific version of Python is necessary (ie, the package contains extension modules). This would leave pure-python packages out in the cold. * Live with the ugly UI that would result in performing that check after the Python version has been selected, and add the command-line processing necessary to make this work. * Ignore the issue and try to educate people that they must explicitly use "Run as Administrator" for such packages on Vista. I'm wondering if anyone has any opinions or thoughts on how we should handle this? Cheers, Mark

4 11

buildout, zc.recipe.testrunner and tests_require
by Nathan R. Yergler Nov. 15, 2007

Nov. 15, 2007

I'm using zc,buildout to manage the development of a very simple web application. I'd like to have a simple test runner that runs my doctests, but have run into a slight problem. I'm using wsgi_intercept to aid in testing, but unfortunately wsgi_intercept isn't a proper Python package ("yet", according to Titus). So I have a package-i-fied version in my svn repository and in my buildout.cfg I specify: develop = . ./wsgi_intercept_ I initially was using the "interpreter" option to get a Python interpreter with my eggs on the path, and running "./bin/python setup.py test". That, however, required me to list wsgi_intercept as a package requirement, when I really want to list it as a testing requirement. Moving it to a testing requirement caused it's develop egg not to be on the PYTHONPATH, so setuptools tries to find it. Which it couldn't. I tried using zc.recipe.testbrowser, thinking that maybe it'd look at the tests_require for the target eggs, but no such luck. The testrunner also seems pretty promiscuous in looking for things to test (it tries to import my eggs directory and test them which predictably doesn't work), but that's another story. So... any suggestions on using zc.buildout along with testing dependencies (generally or with zc.recipe.testrunner)? Thanks, Nathan

4 4

my wishlist for easy_install
by Toni Mueller Sept. 4, 2007

Sept. 4, 2007

Hi, I'd really like to see these two features in easy_install which I can't find right now: 1 - coexist with the operating system/recognize packages which are installed via operating system means 2 - remove packages Currently, when I want to easy_install a package, it starts downloading all sorts of stuff from PYPI although I have already similar (the same - maybe other versions) packages in my system which I installed via the operating system's package manager. I'd really like to not have to manually inspect a prospective package to then manually download and install all dependencies via the package manager, and then to proceed to easy_install -N the offending package, but instead have this process automated. I'd also be able to say something like easy_install -r package to remove such a package, but only if I installed it via easy_install in the first place, leaving operating system installed packages alone. I'm mostly using easy_install on Debian/Linux (Etch), but other platforms (OpenBSD, maybe Solaris) are relevant for me, too. Thanks for listening! Best, --Toni++

3 2

Disabling --single-version-externally-managed
by Ignacio Vazquez-Abrams Sept. 1, 2007

Sept. 1, 2007

I have some packages that I'm using the following with: %{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT I now need to install multiple versions of one of the packages and so need to disable the implicit --single-version-externally-managed. How can I do so and still use setup.py install? -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>

3 7

Obtaining the Egg version from the Python code?
by Andreas Jung Aug. 28, 2007

Aug. 28, 2007

Is there a way to obtain the version info of an egg from with Python code stored with the egg? Usecase: an egg contains several commandline utils (configured and installed using entry point). A dedicated --version option should display the overall version of the egg. Tnx, Andreas

2 1

Uninstall
by Martin Aspeli Aug. 27, 2007

Aug. 27, 2007

Hi all, Someone asked me today, how to uninstall a package that was installed with easy_install. The best I could come up with was, remove the .egg file/directory from site-packages and remove the corresponding line from easy_install.pth. That's pretty lame and error prone. Is there a better way? Martin -- Acquisition is a jealous mistress

3 6

Re: [Distutils] Cannot install pygtk with easy_install
by Phillip J. Eby Aug. 24, 2007

Aug. 24, 2007

At 02:34 PM 8/24/2007 +1000, james.mills(a)au.pwc.com wrote: >When I do a: >python setup.py bdist_wininst > >the resulting installer installs the python package but _does not_ install >setuptools on a system that doesn't have it. > >I've tried to work out what I'm donig wrong for the past couple of hours >now with no luck :/ Would appreciate some help! bdist_wininst (or any bdist_* format other than eggs) doesn't install dependencies. Bundling ez_setup only affects source installs.

1 0

[setuptools]: Installing deps
by james.mills＠au.pwc.com Aug. 23, 2007

Aug. 23, 2007

Hi all, I've followed the documentation for setuptools with regards to installing dependencies and installing setuptools (if it's not instlaled, or upgrading it). I can't however get any of these features of setuptools to work correctly. 1. setuptools is not being installed when users install the application's installer 2. required dependencies arenot being installed either. This is being done on Windows XP machine with Python-2.5.1 I do have ez_setup.py in the same directory as setup.py of the project in question and have the following 2 lines at the top of setup.py: import ez_setup ez_setup.use_setuptools() In my setup.py I have: install_requires = [ "pymills" ], However this is not being installed when the app's installer is run. Also setuptools is not being installed either. Am I missing something ? From what I've read this should _all_ work :) cheers James James Mills PricewaterhouseCoopers Australia Office: +61 (7) 3257 8847 Mobile: 0430 165 904 Fax: +61 (7) 3023 0938 james.mills(a)au.pwc.com http://www.pwc.com/au Please consider the environment before printing this email _________________________________________________________________ Please consider the environment before printing this email. PricewaterhouseCoopers is delighted to be recognised by our clients as the Professional Services Market Leader and Best Accounting Firm (Revenue over $250m) in the BRW-St.George Client Choice Awards 2007. http://www.pwc.com/au/awards PwC's latest news, insights and offerings http://www.pwc.com/au This communication is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking any action in reliance on, this communication by persons or entities other than the intended recipient is prohibited. If you received this in error, please inform PricewaterhouseCoopers ("PwC") immediately by return email and delete the material including all copies from any computer. Liability limited by a scheme approved under Professional Standards Legislation. PwC makes no express or implied representation or warranty that this electronic communication or any attachment is free from computer viruses or other defects or conditions which could damage or interfere with the recipients data, hardware or software. This communication and any attachment may have been modified or otherwise interfered with in the course of transmission.

1 0

Re: [Distutils] Cannot install pygtk with easy_install
by Phillip J. Eby Aug. 23, 2007

Aug. 23, 2007

At 10:49 AM 8/24/2007 +1000, james.mills(a)au.pwc.com wrote: >Best match: pygtk 2.10.4 >Downloading >ftp://ftp.gnome.org/pub/GNOME/sources/pygtk/2.10/pygtk-2.10.4.tar.gz > >... > return self.dict[name.lower()] >KeyError: 'content-type' I could've sworn this problem was already fixed, but as it turns out, it wasn't fixed for actual file downloads. I've fixed it in SVN; you can "easy_install setuptools==dev06" to get the fixed version.

1 0

Cannot install pygtk with easy_install
by james.mills＠au.pwc.com Aug. 23, 2007

Aug. 23, 2007

Hi all, I'm using setuptools-0.6c6 and I run into a problem trying to install pygtk. I am using Python-2.5 on Windows XP D:\>easy_install pygtk Searching for pygtk Reading http://cheeseshop.python.org/pypi/pygtk/ Couldn't find index page for 'pygtk' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://cheeseshop.python.org/pypi/ Reading http://cheeseshop.python.org/pypi/pyGTK/2.0.0 Reading http://www.daa.com.au/~james/software/pygtk/ Reading http://cheeseshop.python.org/pypi/PyGTK/2.10.4 Reading http://www.pygtk.org/ Best match: pygtk 2.10.4 Downloading ftp://ftp.gnome.org/pub/GNOME/sources/pygtk/2.10/pygtk-2.10.4.tar.gz Traceback (most recent call last): File "C:\Python25\Scripts\easy_install-script.py", line 8, in <module> load_entry_point('setuptools==0.6c6', 'console_scripts', 'easy_install')() File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\comm and\easy_install.py", line 1670, in main File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\comm and\easy_install.py", line 1659, in with_ei_usage File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\comm and\easy_install.py", line 1674, in <lambda> 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.6 c6-py2.5.egg\setuptools\comm and\easy_install.py", line 211, in run File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\comm and\easy_install.py", line 433, in easy_install File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\pack age_index.py", line 463, in fetch_distribution File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\pack age_index.py", line 449, in find File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\pack age_index.py", line 392, in download File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\pack age_index.py", line 612, in _download_url File "C:\Python25\lib\site-packages\setuptools-0.6 c6-py2.5.egg\setuptools\pack age_index.py", line 622, in _attempt_download File "C:\Python25\lib\rfc822.py", line 384, in __getitem__ return self.dict[name.lower()] KeyError: 'content-type' D:\> cheers james James Mills PricewaterhouseCoopers Australia Office: +61 (7) 3257 8847 Mobile: 0430 165 904 Fax: +61 (7) 3023 0938 james.mills(a)au.pwc.com http://www.pwc.com/au Please consider the environment before printing this email _________________________________________________________________ Please consider the environment before printing this email. PricewaterhouseCoopers is delighted to be recognised by our clients as the Professional Services Market Leader and Best Accounting Firm (Revenue over $250m) in the BRW-St.George Client Choice Awards 2007. http://www.pwc.com/au/awards PwC's latest news, insights and offerings http://www.pwc.com/au This communication is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking any action in reliance on, this communication by persons or entities other than the intended recipient is prohibited. If you received this in error, please inform PricewaterhouseCoopers ("PwC") immediately by return email and delete the material including all copies from any computer. Liability limited by a scheme approved under Professional Standards Legislation. PwC makes no express or implied representation or warranty that this electronic communication or any attachment is free from computer viruses or other defects or conditions which could damage or interfere with the recipients data, hardware or software. This communication and any attachment may have been modified or otherwise interfered with in the course of transmission.

1 0

easy_install doesn't handle extras properly
by Jim Fulton Aug. 22, 2007

Aug. 22, 2007

Suppose I have a package x that defines an extra y in version 2. In version 3, I remove the extra. Now, if I use easy_install to request x with extra y. easy_install will get the newest x, version 3, and complain that it has no extra y: (env25)jim@ds9:~/tmp$ easy_install -f /home/jim/tmp/x/dist 'x[y]' Searching for x[y] Best match: x 3 Processing x-3-py2.5.egg creating /home/jim/tmp/env25/lib/python2.5/x-3-py2.5.egg Extracting x-3-py2.5.egg to /home/jim/tmp/env25/lib/python2.5 Adding x 3 to easy-install.pth file Installed /home/jim/tmp/env25/lib/python2.5/x-3-py2.5.egg Processing dependencies for x[y] Traceback (most recent call last): ... pkg_resources.UnknownExtra: x 3 has no such extra feature 'y' If I tell easy_install to install a version < 3, then it gets version 2, which has the extra: (env25)jim@ds9:~/tmp$ easy_install -f /home/jim/tmp/x/dist 'x[y] <3' Searching for x[y]<3 Best match: x 2 Processing x-2-py2.5.egg ... Finished installing x[y]<3 easy_install is supposed to get the best distribution that satisfies a requirement, but it doesn't handle the extra part of the requirement. This is just another example of the burden of supporting the feature. Can we *please* get rid of the extras feature. It has some benefit, but I really don't think the benefit justifies the extra complexity in the model or the burden on tool developers. 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

Declaring conflicts
by Thomas Lotze Aug. 22, 2007

Aug. 22, 2007

What's the recommended practice, if any, for declaring conflicts between egg distributions? The use case I have in mind is changing dependencies between packages A and B: * A-1 depends on B-1, but not the other way around, * I want to make B-2 depend on A-2, but not the other way around, * and I want to make sure that if someone has A-1 and B-1 installed, they cannot upgrade only A, because A-2 and B-1 conflict in terms of functionality. AFAICS, nothing prevents people from upgrading only A if only dependencies, but no conflicts are declared. I didn't find any documented way of declaring conflicts, though. -- Thomas

1 0

I finally got the kiva rpm to build using bdist_rpm
by Stanley A. Klein Aug. 21, 2007

Aug. 21, 2007

I finally got the kiva rpm to build. I also got the docs and examples into the proper doc directory. Here is what it took: First, run "python setup.py bdist_rpm", which will fail with a list of installed but unpackaged files. Somehow the full set of installed files isn't being recorded, probably because of some problem among numpy distutils, python distutils, setuptools, and Fedora rpm brp-python-bytecompile that isn't solved by the [install] optimize=1 option in setup.cfg (that works in most cases). Then create a file (I called it problem_files) with a list of the installed but unpackaged files. Also, create a new install script to be put into the rpm spec file that appends the problem file list to INSTALLED_FILES (where the installed files are recorded in the default spec file). Then run the setup with options that use the new install script. The rpm packaging of the docs files is just another option to the setup run. Below are the relevant scripts and files. I think I may still have a problem with the enthought namespace __init__.py and the nspkg.pth file that will presumably be fixed in an upcoming version of setuptools. BTW, I don't know what effect this has, but there are also __init__.pyc and __init__.pyo files packaged into the rpm with the namespace file. IIRC it may not be supposed to be there, but it got in somehow, probably because of the same problem that caused the installed files to be incorrectly recorded. Stan Klein ------------------------------------------------------------------------------------- The setup command line: python setup.py bdist_rpm --doc-files=" examples/ docs/ " --install=install_script2 install_script2 is: python setup.py install --single-version-externally-managed --root= $RPM_BUILD_ROOT --record=INSTALLED_FILES cat /home/stan/new-enthought-svn/enthought.branches/enthought.kiva_2.0/problem_files >> INSTALLED_FILES problem_files is: /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/affine_matrix_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/affine_matrix_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/clip_to_rect_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/clip_to_rect_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/compiled_path_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/compiled_path_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/gcmemtest.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/gcmemtest.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/graphics_context_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/graphics_context_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/image_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/image_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/join_stroke_path_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/join_stroke_path_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/points_in_polygon_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/points_in_polygon_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/rgba_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/rgba_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/stroke_path_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/stroke_path_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_arc.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_arc.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_draw_dash.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_draw_dash.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_ft.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_ft.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_graphics_context_system.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_graphics_context_system.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_image3.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_image3.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_save.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_save.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_utils.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_utils.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/unicode_font_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/unicode_font_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/tests/affine_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/tests/affine_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/tests/basecore2d_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/tests/basecore2d_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/tests/mac_simpletest.pyc /usr/lib/python2.4/site-packages/enthought/kiva/tests/mac_simpletest.pyo /usr/lib/python2.4/site-packages/enthought/kiva/tests/macport_test.pyc /usr/lib/python2.4/site-packages/enthought/kiva/tests/macport_test.pyo

2 4

Buildout now uses the simple index.
by Jim Fulton Aug. 21, 2007

Aug. 21, 2007

As of yesterday's zc.buildout release, buildout now uses the simple package index: http://cheeseshop.python.org/simple by default. (You can cause it to use another index by setting the buildout index option.) This change should provide significantly better performance and will make it easier to use historical releases, because the simple interfaces shows releases that have been hidden from the human interface. It would be nice if easy_install also used the simple interface. 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

Heads up: major change in zc.buildout policy for selecting distributions
by Jim Fulton Aug. 20, 2007

Aug. 20, 2007

I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non-final ones. If there are final and non-final distributions that satisfy a requirement, buildout will, by default, select a final distribution even if there are non-final distributions that satisfy a requirement. This release will cause many existing buildouts to use older distributions than they do now. You can change this behavior by providing a prefer-final buildout option: [buildout] prefer-final = false 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 2

zc.buildout
by Miles Aug. 20, 2007

Aug. 20, 2007

Hi, We have some a zc.buildout-based deployment system, and we're looking at how we can make the process slightly easier for moving between development, testing and production environments. I was wondering if others have a pattern for setting up a buildout in this way? I am imagining that this is better done by running the different steps, but putting the outputs in different locations (e.g. for testing, put apache configurations in some directory in the test tree), rather than trying to selectively run steps (e.g. for testing, i do not want apache configurations set up). Is there a useful buildout.cfg pattern that covers this? Also, one other use-case that we've got is to be able to group parts together into sets. So, for example, I'd lie to be able to do something like: [buildout] parts = awstats [awstats] parts = awstats-download apacheconf-install crontab-install which would tell buildout to run the three parts listed, rather than remembering all 3 specific parts in the parts list. The advantage being to ensure the bits are always run together. Has anyone done anything like this at all? Thanks, Miles

3 3

trouble making egg...
by Chris Withers Aug. 20, 2007

Aug. 20, 2007

Hi All, I've always built my python packages as a folder, with a __init__.py, any other python bits and then the miscellany (readme.txt, etc) in the same folder. For distributions, I've historically tarred up the folder and put it up to download with installation instructions to just untar somewhere on the python path. However, I'd now like to distribute one of my products as an egg, and so thought I'd use setuptools to build the source distros as well. The package is mailinglogger and you can see the svn trunk here: https://secure.simplistix.co.uk/svn/Simplistix/mailinglogger/trunk/ The setup.py there is wrong in that the egg is builds only contains the 'tests' subpackage and none of the other modules, and no mailinglogger package to boot. Given the component.xml in there, I'm pretty sure I need to add a zip_safe=True, but what else do I need to do to get setup.py to correctly build an egg and a source distro? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 6

Re: [Distutils] [Catalog-sig] Simpler Python package management: the "egg" command
by Phillip J. Eby Aug. 20, 2007

Aug. 20, 2007

At 10:59 AM 8/17/2007 +0100, Luis Bruno wrote: >The really *big* -1 this has is that I'm basically gonna be using >--single-version-externally-managed eggs (which makes it impossible to >have multiple "inactive" versions and require() them, if I understood >Phillip Eby correctly). You can have inactive versions and require() them, they just have to be .egg files or directories. You can have a "default" version that's installed --single-version, e.g. by a system package manager such as RPM. >I was thinking "sync local" re-gets the repository's Packages >master-list. Then you read in the locally installed ones (which is a >matter of traversing sys.path and looking for the .egg-info files; I >think those are now (as of 2.5) expected to be there. Please, please, *please* use the published APIs in pkg_resources for this. Too many people are writing tools that inspect egg files and directories directly -- and get it only partly right, making assumptions about the formats that aren't valid across platforms, Python versions, etc., etc. In general, if you are doing absolutely *anything* with on-disk formats of eggs, and you didn't read enough of the docs to find the equivalent APIs, it's a near-certainty that you don't understand the format well enough to write your own versions. Meanwhile, pkg_resources is proposed for inclusion in the Python 2.6 stdlib, so it's not like it's going to be hard to get a hold of. In this particular example, by the way, if you want to find all locally installed packages, you probably want to be using an Environment instance, which indexes all installed packages by package name, and gives you objects you can inspect in a variety of ways, including using .get_metadata('PKG-INFO') calls to read the .egg-info files -- or .egg-info/PKG-INFO, or EGG-INFO/PKG-INFO, or whatever file is actually involved. (This is why you need to use the API -- there are a lot of devils in the details.) >I think easy_install -f <url> can work against an Apache directory >index. Yes. >I thought that was the whole point behind it, really. One of them, anyway. There are other aspects besides -f that work for directory indexes, such as PyPI "home page" and "download" URL links.

1 0

Finding eggs when dependency_links and user specified URLs both given to easy_install?
by Dave Peterson Aug. 20, 2007

Aug. 20, 2007

What happens if a user specifies a URL via a '-f' option on the easy_install command line but our published eggs specify dependency_links in the setup.py? Will easy_install search the user's specified location first, last, or will it not search them at all? (I'm hoping for the first!) I'm asking because we want to provide binaries (eggs) of our projects for various platforms (RHEL3, RHEL4, RHEL5, Ubuntu 7.04, etc.) all of which generate the same egg name, but our projects include C /C++ extensions that require compilation for the specific platform, so we've structured an egg repository that allows us to separate these equivalently named eggs by the actual target platform. We also want users to be able to install from source tar/zip balls for platforms we haven't built binaries for yet, so our eggs all include dependency_links to point at our egg repo. Due to issues with build management, we aren't currently listing the target platform URLs in each egg's setup.py's dependency_links when it gets built on that target platform. It just has the source tar/zip ball repository's URL. But early indications are that when a user installs by doing something like: easy_install -f <enthought platform specific repo url> ets==2.5b2 then the first egg gets found properly in the platform specific repo, but all of its dependencies are only being searched for in the source repo. Is this just a misinterpretation of the output generated by easy_install? BTW, it would be nice if there was an option to name your generated eggs based on a full specification of OS and version, hardware arch, etc. And of course, the whole setuptools universe of tools would need to know to search for eggs with that level of accuracy before dropping down to more generic specs. Another similar use case: Some of our users want to locally cache eggs for distribution within their corporate environment for various reasons (eggs tested and approved to work with their corporate desktop standard, etc.) Those users would also be specifying a '-f' option to easy_install to point at their corporate cache. However, all of our eggs will have dependency_links specified. Will these corporate users be able to install and pull things from their local repository, or will easy_install always look at our dependency_links' specified locations first? It doesn't seem convenient to force them to have to remember to provide a '-H' setting, though I guess their IT group could create an alias or batch script that does this for them. I also guess that their IT group could generate their own version of easy_install that customizes / hard-codes the URLs that it would look at, but that seems like kind of a long way to go to solve this problem. -- Dave

2 1

Simpler Python package management: the "egg" command
by Bjørn Stabell Aug. 20, 2007

Aug. 20, 2007

Hi all, [ I originally posted to catalog-sig(a)python.org, but Jim Fulton recommended I cross-post to this list to as many of the ideas also deal with distutils/setuptools. Please cc replies to catalog- sig(a)python.org as well. ] I think there's a lot to gain for Python by improving PyPI, and I'm willing to help. I did help a bit with PyPI at last year's EuroPython sprint, and was then made aware of http://wiki.python.org/ moin/CheeseShopDev - is this the most up-to-date plans for PyPI? If you're in a hurry and don't want to read everything; 1) I've created a little app to help prototype how we can do better egg/package management at http://contrib.exoweb.net/trac/browser/egg/ 2) I'd like feedback, and pointers to how I can help more. Basically, the problems I would like to work on solving are: 1) Simplifying/enabling discovery of packages 2) Simplifying/enabling management of packages 3) Improving quality and usefulness of package index From a usability point-of view I'd like to focus on the requirements for the Python newbie, someone that has just discovered Python, but is probably used to package management systems from Linux distributions, FreeBSD, and other dynamic languages like Perl and Ruby (these are also the systems I have experience with, so I'm pulling ideas from them). Ideally everything should be (following Steve Krug's "Don't Make Me Think" recommendations) self-evident, and if that's not possible, at least self-explanatory. Someone put in front of a keyboard without having read any docs should be able to find, install, manage, and perhaps even create Python packages. Better usability will of course benefit everyone, not just beginners. I'm frankly amazed at how people that have programmed Python for years don't really know or use PyPI. I'm convinced making more of Python package system discoverable and easily accessible will greatly improve the adoption of Python, the number of Python packages, and the quality of these packages. I think the typical use cases would be (in order of importance, based on what a typical user would encounter first): * Find available eggs for a particular topic online * Get more information about an egg * Install an egg (and its dependencies) * See which eggs are installed * Upgrade some or all outdated eggs * Remove/uninstall an egg * Create an egg * Find eggs that are plugins for some framework online NAMING So, first of all we'll need either one command, or a set of similarly named commands, to do discovery, installation, and management of packages, as these are common end-user actions. Creation of packages is a bit more advanced, and could be in another command. If there's general agreement that Python eggs is the future way of distributing packages, why not call the command "egg", similar to the way many other package managers are named after the packages, e.g., rpm, port, gem? I'll assume that's the case. Next, where do you find eggs? This might not be a big issue if the "egg" command is configured properly by default, but I'd offer my thoughts. I know the cheeseshop just changed name back to PyPI again. In my opinion, neither of the names are good in that they don't help people remember; any Monty Python connection is lost on the big masses, and PyPI is hard to spell, not very obvious, and a confusing clash with the also-prominent PyPy project. Why not call the place for eggs just eggs? I.e., http://eggs.python.org/ So we'd have the command "egg" for managing eggs that are by default found at "eggs.python.org". I think it's hard to make Python package management more obvious that this. The goal is to get someone that is new to Python to remember how to get and where to find packages, so obvious is a good thing. THE COMMAND LINE PACKAGE MANAGEMENT TOOL The "egg" command should enable you to at least find, show info for, install, and uninstall packages. I think the most common way to do command line tools like this is to offer sub-commands, a la, bzr, port, svn, apt-get, gem, so I suggest: egg - list out a help of commands egg search - search for eggs (aliases: find/list) egg info - show info for egg (aliases: show/details) egg install - install named eggs egg uninstall - uninstall eggs (aliases: remove/purge/delete) so you can do: egg search bittorrent to find all packages that have anything to do with bittorrent (full- text search of the package index), and then: egg install iTorrent to actually download and install the package. PROTOTYPE I've built a prototype for a command that works this way, implementing most (except the last) of the use cases at least partiall. You can give it a go as follows: # install prerequisities on your platform # e.g., sudo apt-get install python-setuptools sqlite3 libsqlite3-0 python-pysqlite2 svn co http://contrib.exoweb.net/svn/egg/ cd egg sudo python setup.py develop # should install storm for you gzip -dc pypi.sql.gz | sqlite3 ~/.pythoneggs.db # bootstrap cache egg sync # update cache It's still incomplete, lacking tests, might only work on unix-y computers, and is lacking support for lots of features like activation/deactivation, and upgrades, but it works for basic stuff like finding, installing, and uninstalling packages. Summary of the design: * Local and PyPI package information is synchronized into a local sqlite database for easy access * Storm is used for ORM (but could easily be changed) * Installation is handled by passing off the "egg install" command to "easy_install" * I'm using a non-standard command-line parser (but could easily be changed) * For interactive use on terminals that supports it: colorizes and adjusts text to fit While doing the synchronization with PyPI I discovered a couple of issues, described below, that makes the application unfit for common use yet. (Eg., it has to query the PyPI for each of the packages.) Most subcommands take arguments that can be a free mix of set names and query strings. I thought this would make for the most forgiving and user-friendly interface. These are filters; by default all eggs match. SETS: Eggs have a few attributes that can be used to limit to a subset of all eggs, e.g., whether it is installed, active, oudated, local, or remote. Specifying several of these creates a join of the sets, it further limits the number of eggs. QUERY STRINGS: If none of the set names are matched, the argument is assumed to be a query string. Many subcommands like "search" do a full-text search of the package cache database. Others, like "list", will do a substring match of package names. Others, like "install" will require you to match the name exactly. You can specify a specific version by adding a slash, e.g., "name/version". Here are some example commands: egg list installed sql - list all installed eggs having sql in their name egg search installed sql - list all installed eggs mentioning sql anywhere in the package metadata egg list oudated installed - list all outdated installed eggs egg list oudated active - list all outdated and active (and installed) eggs egg uninstall outdated - uninstall all oudated eggs egg info pysqlite - show information about pysqlite egg info pysqlite/2.0.0 - show information about version 2.0.0 of pysqlite egg sync local - rescan local packages and update cache db PYPI IMPROVEMENT SUGGESTIONS While doing the application I discovered one important missing feature: PyPI doesn't offer a way to programatically bulk-download information about all eggs, as is customary for many other packaging systems. This means "egg sync" will have to fetch the information for each package individually. I think it wouldn't be hard to offer a compressed XML file with all of the package information, suitable for download. A minor nuiscence is that there's no way to get only eggs/ distributions; PyPI lists packages, and some packages don't even have any eggs. The "egg" command will try to download each of these empty packages at each sync (since it treats empty packages as "packages for which we haven't downloaded eggs for yet"). It might be better to list eggs/distributions instead of packages. There's a lot of opportunity in improving the consistency and usefulness of package metainformation. Once you have it all sync'ed to a local SQlite database and start snooping around, it'll be pretty obvious; very few packages use the dependencies etc. (In fact, I think the dependencies/obsoletes definitions are overengineered; we could get by with just a simple package >= version number). Many people use other platform-specific packaging system to manage Python packages, probably both because this gives dependencies to other non-Python packages, but also because PyPI hasn't been very useful or easy to use. It may even be asked what the role of PyPI is since it's never going to replace platform-specific packaging systems; then should it support them? How? In any case, installing Python packages from different packaging systems would result in problems, and currently "egg" can't find Python packages installed using other systems. ("Yolk" has some support for discovering Python packages installed using Gentoo.) Optional: These days XMLRPC (and the WS-Deathstar) seems to be losing steam to REST, so I think we'd gain a lot of "hackability" by enabling a REST interface for accessing packages. Eventually we probably need to enforce package signing. EGG IDEAS It'd be good for "egg" to support both system- and user-wide configurations, and to support downloading from several package indexes, like apt-get does. Perhaps "egg" should keep the uninstalled packages in a cache, like apt-get and I believe buildout. Perhaps "egg" should provide a simple web server to allow browsing (and perhaps installation from) local packages (I believe the Ruby guys have this). If this web server should be discoverable via Bonjour/Zeroconf, then all that's needed to set up a cache of PyPI is to run an egg server (that people on the net auto-discovers) and regularly download all packages. How could "egg" work with "buildout"? Should buildout be used for project-specific egg installations? There area lot of other ideas and thoughts in the TODO.txt file of the egg command, and I agree it's a good idea to join forces (distutils, setuptools, yolk, enstaller, PythonEggTools, ...). Rgds, Bjorn

7 7

Re: [Distutils] PyPI - Evolve our own or reuse existing package systems?
by Bjørn Stabell Aug. 17, 2007

Aug. 17, 2007

(Since my email was a bit long and wide I'm trying to update the subject when the response is rather focused.) On Aug 15, 2007, at 06:37, Paul Boddie wrote: > Bjørn Stabell wrote: [...] > I've been moderately negative about evolving a parallel > infrastructure to > other package and dependency management systems in the past, and > I'm not > enthusiastic about things like CPAN or language-specific > equivalents. The > first thing most people using a GNU/Linux or *BSD distribution are > likely to > wonder is, "Where are the Python packages in my package selector?" > > There are exceptions, of course. Some people may be sufficiently > indoctrinated > in the ways of Python, which I doubt is the case for a lot of > people looking > for packages. Others may be working in restricted environments > where system > package management tools don't really help. And people coming from > Perl might > wonder where the CPAN equivalent is, but they should also remind > themselves > what the system provides - they have manpages for Perl, after all. [...] > I've read through the text that I've mercilessly cut from this > response, and I > admire the scope of this effort, but I do wonder whether we > couldn't make use > of existing projects (as others have noted), and not only at the > Python-specific level, especially since the user interface to the > "egg" tool > seems to strongly resemble other established tools - as you seem to > admit in > this and later messages, Bjørn. [...] > I was thinking of re-using the Debian indexing strategy. It's very > simple, > perhaps almost quaintly so, but a lot of the problems revealed with > the > current strategies around PyPI (not exactly mitigated by bizarre > tool-related > constraints) could be solved by adopting existing well-worn > techniques. [...] > If I recall correctly, the PEP concerned just "bailed" on the version > numbering and dependency management issue, despite seeming to be > inspired by > Debian or RPM-style syntax. [...] > As I've said before, it's arguably best to work with whatever is > already > there, particularly because of the "interface" issue you mention with > non-Python packages. I suppose the apparent lack of an open and > widespread > package/dependency management system on Windows (and some UNIX > flavours) can > be used as a justification to write something entirely new, but I > imagine > that only very specific tools need writing in order to make existing > distribution mechanisms work with Windows - there's no need to > duplicate > existing work from end to end "just because". [...] > Agreed. And by adopting existing mechanisms, we can hopefully avoid > having to > reinvent their feature sets, too. > > P.S. Sorry if this sounds a bit negative, but I've been reading the > archives > of the catalog-sig for a while now, and it's a bit painful reading > about how > sensitive various projects are to downtime in PyPI, how various > workarounds > have been devised with accompanying whisper campaigns to tell > people where > unofficial mirrors are, all whilst the business of package > distribution > continues uninterrupted in numerous other communities. > > If I had a critical need to get Python packages directly from their > authors to > run on a Windows machine, for example, I'd want to know how to do > so via a > Debian package channel or something like that. This isn't original > thought: > I'm sure that Ximian Red Carpet and Red Hat Network address many > related > issues. There seems to be two issues: 1) Should Python have its own package management system (with dependencies etc) in parallel with what's already on many platforms (at least Linux and OS X)? Anyone that has worked with two parallel package management systems knows that dependencies are hellish. * If you mix and match you often end up with two of everything. * It'll be incomplete because you can't easily specify dependencies to non-Python packages. 2) If we agree Python should have a package management system, should we build or repurpose some other one? * I think it's a matter of pride and proof of concept to have one written in Python. That doesn't mean we can't get ideas from others. * It's also not that hard to do. The prototype I threw up took one weekend + half a day, and consists of about 500 lines of new code. It could be refactored and made smaller, but even if a complete version is ten times the size of that, it's still not a huge undertaking. * With a Python version we could relatively easily innovate beyond what traditional packaging systems do; ports and apt are pretty much stagnated. I think RubyGems seems to have some cool features, features that probably wouldn't have happened if they were using ports or apt-get (but then they could piggyback on innovations in those tools, I guess). If it works for them, why shouldn't it work for us? * It would have to be as portable as Python is; many packaging systems are by nature relatively platform-specific. * If we don't build our own, doesn't that mean we throw out eggs? * Packaging systems are useful for mega frameworks like Zope, TurboGears, and Django, and slightly less so for projects you roll on your own, to manage distribution and installation of plugins and addons. Relying on platform-specific packaging systems for these may not work that well. (But I could be wrong about that.) That said, it might be possible to do some kind of hybrid, for PyPI to be a "meta package" repository that can easily feed into platform specific packaging systems. And to perhaps also have a client-side "meta package manager" that will call upon the platform-specific package manager to install stuff. It looks like, for example, ports have targets to build to other systems, e.g., pkg, mpkg, dmg, rpm, srpm, dpkg. So maintaining package information in (or compatible with) ports could make it easy to feed packages into other package systems. * Benefit: We're working with other package systems, just making it easier to get Python packages into them. * Drawback: They may not want to include all packages, at the speed at which we want, or the way we want to. (I.e., there may still be packages you'd want that are only available on PyPI.) * Drawback: Some systems don't have package systems. Which brings me to: If we're just distributing source files why don't we use a source control system such as svn, bzr, or hg? The package developers have trunk, PyPI is a branch, the platform-specific package maintainers have a branch, and what's installed onto your system is in the end a branch (serially connected). Some systems, like Subversion, can also include externals like I did with cliutils on the egg package. Just a thought. Rgds, Bjorn

4 5

Where is easy_install finding this dependency from?
by Dave Peterson Aug. 16, 2007

Aug. 16, 2007

We've gotten a number of problem reports from people trying to install our egg releases where there doesn't seem to be enough information being output to the console to really debug the problem. Here's an illustrating log taken from a user's report: ======= C:\Documents and Settings\Gary>easy_install -f http://code.enthought.com/enstaller/eggs/windows/xp ets Searching for ets Reading http://code.enthought.com/enstaller/eggs/windows/xp Best match: ets 2.5b2 Downloading http://code.enthought.com/enstaller/eggs/windows/xp/ets-2.5b2-py2.5.egg Processing ets-2.5b2-py2.5.egg Moving ets-2.5b2-py2.5.egg to c:\python25\lib\site-packages Adding ets 2.5b2 to easy-install.pth file Installed c:\python25\lib\site-packages\ets-2.5b2-py2.5.egg Reading http://code.enthought.com/enstaller/eggs/source Reading http://code.enthought.com/enstaller/eggs/source/unstable Processing dependencies for ets Searching for wx==2.6 Reading http://cheeseshop.python.org/pypi/wx/ Couldn't find index page for 'wx' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://cheeseshop.python.org/pypi/ No local packages or download links found for wx==2.6 error: Could not find suitable distribution for Requirement.parse ('wx==2.6') ======= I've verified that our 'ets' egg does not even mention 'wx' in its setup.py so something else on this user's system must be requiring it, right? But there's no information here about where the requirement came from. In fact the situation is even worse than that because easy_install outputs the line about processing dependencies for ets, but the next step is about some other egg's dependencies and not one of the 20+ dependencies actually listed in the 'ets' egg. Can easy_install be updated to inform the user of which egg, or the first one if there are many of them, that generated the requirement on each thing it is trying to install? I'm thinking of a change in the line that looks like: Searching for wx==2.6 to something like Searching for wx==2.6 (required by foo.bar-1.0) It also seems like the error line should indicate which egg generated the requirement for 'wx==2.6', right? -- Dave

1 0

[Fwd: Re: [Enthought-dev] problem easy_installing kiva: agg.i missing]
by Stanley A. Klein Aug. 14, 2007

Aug. 14, 2007

FYI - The issues discussed here combine problems specific to the enthought system with problems using setuptools (that are used if available for parts of the packaging for Kiva). ---------------------------- Original Message ---------------------------- Subject: Re: [Enthought-dev] problem easy_installing kiva: agg.i missing From: "Stanley A. Klein" <sklein(a)cpcug.org> Date: Tue, August 14, 2007 11:46 am To: enthought-dev(a)mail.enthought.com Cc: "Dave Peterson" <dpeterson(a)enthought.com> -------------------------------------------------------------------------- Dave - I need to remove the files from the Kiva rpm for two reasons. First, they don't belong in python/site-packages on a *nix system if compliance with the *nix File Hierarchy Standard and/or the Linux Standards Baxe (that cites the FHS) is desired. If they are in the rpm they need to go somewhere else. I can fix that by declaring the docs files in the setup.cfg file. I tried that fix, although I don't know if I did it correctly and it didn't resolve both problems. Second, they are causing trouble in running the bdist_rpm because their .pyc and .pyo files are producing an "installed but unpackaged files" error. That is somewhat peculiar to Fedora (and RedHat) because SE-Linux needs to know what files are in sensitive directories or it may think they might have been put there by an intruder and thus block access to them. That problem may be due to the lack of __init__.py files (even blank ones) in the relevant directories. Setuptools apparently looks for __init__.py files to guide its processing. I could put in blank __init__.py files and see what that does. However, I would rather fix both problems (the packaging error and the file placement) at the same time. I figured the easiest way to fix the problem is to get the directories out of Kiva and into somewhere else (a Kiva docs directory that includes tests, examples, and docs). I possibly need to go back, put in the blank __init__.py files in a lot of places (the problem is inconsistent and I can't figure out why that happens) and declare the docs as going into the proper FHS place. Stan Klein On Tue, August 14, 2007 8:58 am, Dave Peterson <dpeterson(a)enthought.com> wrote: > Message: 1 > Date: Mon, 13 Aug 2007 20:23:31 -0500 > From: Dave Peterson <dpeterson(a)enthought.com> > Subject: Re: [Enthought-dev] problem easy_installing kiva: agg.i > missing > > Hi Stan, > > Unfortunately, I've never tried to do a bdist_rpm so I'm at a loss on > what might be going on here. But if I had to guess, I'm wondering if > setuptools uses the .svn dirs for its build process -- these won't be > updated by a local svn mv that hasn't been committed yet so it wouldn't > surprise me that even doing an rm -rf wouldn't get rid of the record of > them. In fact, this seems like it would actively cause the error > mentioned below -- you've removed the file but setuptools thinks they > should exist since there is a record in svn. > > Why do they need to be removed from the rpm? > > > -- Dave > > > Stanley A. Klein wrote: >> I svn-updated my enthought.branches/enthought.kiva. >> >> The build worked. >> >> I'm now back to having problems with unpackaged files and am working on >> that issue, which is becoming very strange as well. >> >> I have tried to get all the files not needed for Kiva operation out into >> a >> separate directory (called kiva_docs) at the enthought.branches level. >> That includes the directories kiva/tests, kiva/agg/tests, >> kiva/agg/examples, and kiva/agg/docs, plus some others that I also can't >> seem to get rid of but don't seem to create the same error condition. I >> did an "svn mv". I went in and did an "rm -rf" of the directories. >> However, it seems that the files I thought I got rid of always seem to >> keep getting found, included as files to be installed, and creating >> problems with "installed but unpackaged files" error of rpm. >> >> >> Stan Klein >> >> >> On Mon, August 13, 2007 2:26 pm, Dave Peterson <dpeterson(a)enthought.com> >> wrote: >> ------------------------------ >> >>> Message: 4 >>> Date: Mon, 13 Aug 2007 12:41:24 -0500 >>> From: Dave Peterson <dpeterson(a)enthought.com> >>> Subject: Re: [Enthought-dev] problem easy_installing kiva: agg.i >>> missing >>> >> >> >>> I'm curious if you've tried this on the latest unstable kiva? The svn >>> version is currently in branches and the source tarball is in the >>> unstable dir. I'm talking about enthought.kiva-2.0.0b2.dev here. >>> >>> -- Dave >>> >>> >>> Stanley A. Klein wrote: >>> >>>> I'm having a very similar problem when I try to do "python setup.py >>>> bdist_rpm" on kiva. When I run "python setup.py build" it completes >>>> properly. The bdist_rpm creates an rpm spec file with the same >>>> command >>>> (or by adding an option I can make it the same command). However, >>>> when >>>> the spec file runs, I get the error message about it not being able to >>>> find agg_wrap.c. >>>> >>>> My traceback (below) points to the error arising in the numpy >>>> distutils. >>>> I wonder if this has anything to do with setuptools being svn aware. >>>> I >>>> can imagine a possible cause being some anomaly in the embedded svn >>>> information for kiva. >>>> >>>> I hope this additional information helps. >>>> >>>> >>>> Stan Klein >>>> >> >> [remainder deleted] -- Stanley A. Klein, D.Sc. Managing Principal Open Secure Energy Control Systems, LLC 8070 Georgia Avenue Silver Spring, MD 20910 301-565-4025

1 0

Tiny little zc.buildout documentation bug
by Jeff Shell Aug. 13, 2007

Aug. 13, 2007

I'm only on day two or three of our great modernization and buildout experiment. Today I decided to set up my user defaults and try out the download cache. The documentation says: If the file $HOME/.buildout/defaults.cfg, exists, it is read before reading the configuration file So I went ahead and made a "defaults.cfg" in my $HOME/.buildout directory. But it didn't seem to do anything. The problem is that this first mention of the user-defaults config file uses the plural "defaults.cfg". The system itself expects the singular "default.cfg", and the test/example code immediately following the above line uses the singular 'default.cfg'. -- Jeff Shell

3 2

Execute Installer in quiet mode
by Sylvain Taverne Aug. 10, 2007

Aug. 10, 2007

Hi, Is it possible to execute the installer generate with the command : python setup.py bdist_wininst In a quiet mode ? Thank's -- Sylvain

2 1

Namespace packages and egg-info confusion when using bdist_rpm
by Stanley A. Klein Aug. 9, 2007

Aug. 9, 2007

I've been trying to build rpms of enthought system components. Some of them use namespace packages. Those packages have the required __init__.py files containing "__import__('pkg_resources').declare_namespace(__name__)". According to the Setuptools Guide, these __init__.py files are not to be packaged when using "system" packaging (such as bdist_rpm) and when I run bdist_rpm they are not included in the rpms. However, there are egg-info directories and nspkg.pth files produced, included in the rpms, and installed in site-packages. When I tried to run the enthought example applications, I had various kinds of import failures. I found that fixing them required putting the unpackaged __init__.py files into the relevant directories in the namespace packages. The various rpms were being placed in the proper locations where they should have been found for importing. There were some strange errors, such as in one case when I tried to test the imports interactively an "import a.b.c" worked, but an "import a.b.c as c" failed. Before putting in the __init__.py files, I tried removing the egg-info and nspkg.pth files from site_packages. That did not improve things. I also noticed that some other packages had pth files in site-packages, so that may be what is needed if the egg-info and nspkg.pth are removed, although I don't know why or what the pth files are supposed to contain. I think setuptools is somehow not properly processing bdist_rpm if there are namespace packages involved. Also, the setuptools don't seem to have an option to not create the egg info and nspkg.pth files and/or to not package them if bdist_rpm is being used. Stan Klein

4 10

setuptools controversy (was Re: Prototype setuptools-specific PyPI index.)
by Phillip J. Eby Aug. 8, 2007

Aug. 8, 2007

At 12:56 AM 7/23/2007 -0400, Fred Drake wrote: >On 7/22/07, Phillip J. Eby <pje(a)telecommunity.com> wrote: >>Setuptools has lots of features that are targeted at different >>audiences. There are plenty of features targeted at the group you're >>in, don't begrudge the other groups their features. :) > >Actually, I suspect this is a substantial contributor to setuptools >being considered controversial: it encompasses to many different >features. That's precisely my point, though: "too many" always means "has features I don't use", even though the features one person uses are considered superfluous by other parties, who consider the first person's "superfluous" features essential. However, I'm entirely reconciled to it being controversial. It is in fact impossible to have a significant impact on *anything* without creating controversy, as anyone involved with the history of Zope should be well aware. ;-) Usually, people think they can get away with making "simpler" versions of Zope because they don't understand the full range of requirements which it is intended to meet. The situation with setuptools is much the same, except that sometimes now it's the Zope folks making the accusations of too many features, excess complexity, evil, etc. :)

5 5

Windows web based installation of multiple packages
by Lloyd Kvam Aug. 8, 2007

Aug. 8, 2007

(I normally work from Linux, but have a test WinXP computer and my old WinNT4 with Visual Studio 6 should that turn out to be useful.) It is quite easy to use the bdist_wininst command to create a Windows installer executable. A browser click on a link to the .EXE file allows for software installation, but easy_install is not run and the packages listed in setup.install_requires are not installed. Is there a way to force the windows installer to run easy_install? If I were to create an egg, is there a content-type heading that would cause easy_install to process the egg? (much like application/vnd.ms-excel) I could not find an easy_install entry in the registry in my test WinXP computer after installing setuptools. I thought one of these approaches would be fairly easy, but googling and experimenting have gotten me nowhere. -- Lloyd Kvam Venix Corp

3 5

One windows installer with PIL, docutils and itools for python 2.5
by Sylvain Taverne Aug. 8, 2007

Aug. 8, 2007

Hello, We need to make an executable installer for MS Windows, we guess using bdist_wininst. The installer should package in one single installation on python 2.5 PIL, docutils and itools. We should rather not compile PIL on windows (it's big) but use perhaps the binary distribution for windows: http://effbot.org/downloads/PIL-1.1.6.win32-py2.5.exe Thank's -- Sylvain

1 0

Re: [Distutils] setuptools, eggs, and setup.py in the root of a package - how?
by Phillip J. Eby Aug. 7, 2007

Aug. 7, 2007

At 07:23 PM 8/7/2007 -0600, Jeff Shell wrote: >So we've never done much with eggs or distutils up until now at my >company. We've generally worked in Zope. We generally check out Python >packages directly into a directory where Zope would automatically pick >them up. So we've never gotten into any convention of having a layout >that I commonly see these days: > > distroot > - setup.py > + src > + ourlib > - __init__.py > - etc... > >Fearing that we'd have to dramatically change our source code around, >and shake up existing checkouts, I've avoided trying to add any >distutils/setuptools support to these packages. But I was told >recently that I could have `setup.py` in the package root (`ourlib` in >the example above). You can, but putting it one level higher (e.g. 'src') would be much better. Putting it inside the package means you can't get the "develop" or "test" commands to work correctly... as you mention below. > I've seen this work in a plain distutils system >(Chris McDonough's BuildIt), but I've had a nightmare of a time >getting it to work with setuptools and zc.buildout and on and on. > >Some code lies below that tries to explain the dilemma and shows my >best guess efforts so far. Has anyone had any success with this >layout? > >I was trying to use this as a 'develop' egg(?) using `zc.buildout`, >and it doesn't work. In a generated 'virtual-python' kind of thing, it >sets up this in sys.path (when specifying ``develop=src/ourlib`` in >`buildout.cfg`): > > sys.path[0:0] = [ > '/Users/jshell/Documents/Programming/eggify/src/fdlib', > ... > >This seems like an uphill battle. Any tips? "develop" won't work unless your project directory contains packages; i.e., setup.py has to be in "src" for this to work. That's because some directory needs to get put in sys.path, that has both the .egg-info/ dir and the actual packages as subdirectories.

1 0

setuptools, eggs, and setup.py in the root of a package - how?
by Jeff Shell Aug. 7, 2007

Aug. 7, 2007

So we've never done much with eggs or distutils up until now at my company. We've generally worked in Zope. We generally check out Python packages directly into a directory where Zope would automatically pick them up. So we've never gotten into any convention of having a layout that I commonly see these days: distroot - setup.py + src + ourlib - __init__.py - etc... Fearing that we'd have to dramatically change our source code around, and shake up existing checkouts, I've avoided trying to add any distutils/setuptools support to these packages. But I was told recently that I could have `setup.py` in the package root (`ourlib` in the example above). I've seen this work in a plain distutils system (Chris McDonough's BuildIt), but I've had a nightmare of a time getting it to work with setuptools and zc.buildout and on and on. Some code lies below that tries to explain the dilemma and shows my best guess efforts so far. Has anyone had any success with this layout? I was trying to use this as a 'develop' egg(?) using `zc.buildout`, and it doesn't work. In a generated 'virtual-python' kind of thing, it sets up this in sys.path (when specifying ``develop=src/ourlib`` in `buildout.cfg`): sys.path[0:0] = [ '/Users/jshell/Documents/Programming/eggify/src/fdlib', ... This seems like an uphill battle. Any tips? My fallback plan is to have a separate 'releases' area of our repository which houses setup.py and such for each of these packages along with a script to check out the main source before building an distribution or using as a develop-egg-thing. Is there anything, specific to this problem, that I can be doing better with this setup.py? from setuptools import setup, find_packages def list_packages(): packages = [ 'ourlib.%s' % subpackage for subpackage in find_packages() ] packages.insert(0, 'ourlib') return packages setup( name = 'ourlib', version = "1.0a1", packages = list_packages(), package_dir = {'ourlib': '.'}, include_package_data = True, install_requires=['setuptools'], extras_require = dict( test = ['zope.testing'], ), zip_safe = False, ) Without that 'list_packages', the results of `find_packages` would return 'toolkit' instead of 'ourlib.toolkit': the package head that would normally be there is off. Thanks, Jeff Shell

1 0

setuptools bbfreeze install egg error
by veki Aug. 7, 2007

Aug. 7, 2007

Hello, I was download egg file bbfreeze-0.95.2-py2.4-win32.egg ( for windows of course ),and I have setuptools version 0.6c6 after I try install this with setuptools: $ ez_setup bbfreeze-0.95.2-py2.4-win32.egg Traceback (most recent call last): File "C:\Python24\Lib\site-packages\ez_setup.py", line 226, in ? main(sys.argv[1:]) File "C:\Python24\Lib\site-packages\ez_setup.py", line 183, in main from setuptools.command.easy_install import main File "C:\Python24\Lib\site-packages\setuptools\command \easy_install.py", line 16, in ? from distutils import log,dir_util ImportError: cannot import name log Regards, Vedran __________________________________________________________________ Vedran veki ICQ#: 264412055 Current ICQ status: + More ways to contact me Get ICQ! __________________________________________________________________

1 0

Re: [Distutils] How can I get setuptools to include files beyond what find_packages() finds?
by Stanley A. Klein Aug. 6, 2007

Aug. 6, 2007

Robert Kern wrote: Stanley A. Klein wrote: >> I tried to do something to fix the numpy distutils bdist_rpm.py (by >> trying to follow what was done in install.py) but it didn't work and I >> got an error message I didn't understand. >I'd like to help, but if you don't copy the exact error message here, I can't. OK, here is my revised numpy/distutils/commands/bdist_rpm.py (trying -- obviously not well -- to follow what was done in numpy/distutils/commands/install.py: import os import sys if 'setuptools' in sys.modules: import setuptools.command.bdist_rpm as old_bdist_rpm class bdist_rpm(old_bdist_rpm): pass else: from distutils.command.bdist_rpm import bdist_rpm as old_bdist_rpm class bdist_rpm(old_bdist_rpm): def _make_spec_file(self): spec_file = old_bdist_rpm._make_spec_file(self) # Replace hardcoded setup.py script name # with the real setup script name. setup_py = os.path.basename(sys.argv[0]) if setup_py == 'setup.py': return spec_file new_spec_file = [] for line in spec_file: line = line.replace('setup.py',setup_py) new_spec_file.append(line) return new_spec_file And here is the error message I got (using the kiva setup.py): [stan@localhost enthought.kiva_2.0]$ python setup.py bdist_rpm Traceback (most recent call last): File "setup.py", line 2, in ? from numpy.distutils.core import setup File "/usr/lib/python2.4/site-packages/numpy/distutils/core.py", line 32, in ? from numpy.distutils.command import bdist_rpm File "/usr/lib/python2.4/site-packages/numpy/distutils/command/bdist_rpm.py", line 6, in ? class bdist_rpm(old_bdist_rpm): TypeError: Error when calling the metaclass bases module.__init__() takes at most 2 arguments (3 given) BTW, below is what the unpackaged files error looks like (with a traceback generated by having the DISTUTILS_DEBUG environment variable set). In a much earlier thread I learned that this can usually be resolved by setting [install] optimize=1 in setup.cfg. --------------------------------------------------------------------------- Installed (but unpackaged) file(s) found: /usr/lib/python2.4/site-packages/enthought/__init__.pyc /usr/lib/python2.4/site-packages/enthought/__init__.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/benchmark.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/benchmark.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/conv.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/conv.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/dash.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/dash.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/lion.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/lion.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/lion_data.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/lion_data.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/polygon_hit_test.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/polygon_hit_test.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/rect.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/rect.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple2.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple2.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple_clip.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/simple_clip.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star1.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star1.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star2.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star2.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star_path.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/star_path.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/sub_path.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/sub_path.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/text_ex.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/text_ex.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/tk_ex.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/tk_ex.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_brain.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_brain.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_demo.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_demo.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_image_copy.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_image_copy.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_lines.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_lines.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_lion.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/examples/wx_lion.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/affine_matrix_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/affine_matrix_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/clip_to_rect_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/clip_to_rect_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/compiled_path_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/compiled_path_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/gcmemtest.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/gcmemtest.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/graphics_context_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/graphics_context_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/image_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/image_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/join_stroke_path_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/join_stroke_path_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/points_in_polygon_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/points_in_polygon_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/rgba_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/rgba_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/stroke_path_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/stroke_path_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_arc.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_arc.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_draw_dash.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_draw_dash.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_ft.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_ft.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_graphics_context_system.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_graphics_context_system.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_image3.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_image3.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_save.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_save.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_utils.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/test_utils.pyo /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/unicode_font_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/agg/tests/unicode_font_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/tests/affine_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/tests/affine_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/tests/basecore2d_test_case.pyc /usr/lib/python2.4/site-packages/enthought/kiva/tests/basecore2d_test_case.pyo /usr/lib/python2.4/site-packages/enthought/kiva/tests/mac_simpletest.pyc /usr/lib/python2.4/site-packages/enthought/kiva/tests/mac_simpletest.pyo /usr/lib/python2.4/site-packages/enthought/kiva/tests/macport_test.pyc /usr/lib/python2.4/site-packages/enthought/kiva/tests/macport_test.pyo Traceback (most recent call last): File "setup.py", line 108, in ? version = '2.0b1', File "/usr/lib/python2.4/site-packages/numpy/distutils/core.py", line 174, in setup return old_setup(**new_attr) File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/distutils/command/bdist_rpm.py", line 365, in run self.spawn(rpm_cmd) File "/usr/lib/python2.4/distutils/cmd.py", line 398, in spawn spawn(cmd, search_path, dry_run= self.dry_run) File "/usr/lib/python2.4/distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/usr/lib/python2.4/distutils/spawn.py", line 165, in _spawn_posix raise DistutilsExecError, \ distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

3 5

Re: [Distutils] CVS/Entries.Log ignored by setuptools default CVS file-finder logic
by Phillip J. Eby Aug. 6, 2007

Aug. 6, 2007

At 11:31 AM 8/6/2007 -0600, Jeff Shell wrote: >On 8/6/07, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > At 07:57 AM 8/6/2007 -0600, Jeff Shell wrote: > > >A basic fix appears to be easy: add another `re_finder` for > > >`CVS/Entries.Log` with a regex like ``^A\s\w?/([^/]+)/``. > > > > I'd add this, but since I don't have data to test it on and you > > apparently do, please send a tested patch and I'll add it to the > next version. > >By "tested patch", do you want a unit test to accompany the patch? Or >do you just want it to have been tested by me and compared against the >current release? The latter. >In any case, I think I have such a patch. Where to send? Me, the list, or both. :)

3 3

Re: [Distutils] CVS/Entries.Log ignored by setuptools default CVS file-finder logic
by Phillip J. Eby Aug. 6, 2007

Aug. 6, 2007

At 07:57 AM 8/6/2007 -0600, Jeff Shell wrote: >A basic fix appears to be easy: add another `re_finder` for >`CVS/Entries.Log` with a regex like ``^A\s\w?/([^/]+)/``. I'd add this, but since I don't have data to test it on and you apparently do, please send a tested patch and I'll add it to the next version. >I'm sure I >could add something like this with an entry-point and our own egg, but >it seems ridiculously small for us to maintain internally. Of course; it should be in setuptools. It's just been years since I've used CVS, and I've never encountered this issue.

3 2

Re: [Distutils] bug in svn detection
by Phillip J. Eby Aug. 6, 2007

Aug. 6, 2007

At 06:46 PM 8/5/2007 -0700, Keith Dart â wrote: >Phillip J. Eby wrote the following on 2007-08-05 at 18:31 PDT: >=== > > I don't see why; the fixes are already in setuptools SVN repository, > > as you can see here in r56277. AFAIK, this code is in setuptools > > 0.6c6, i.e., the current release. > >=== > >Oh, ok. It's fixed already. I didn't know you knew about it. Yes, I am >using 0.6c6, since that is the recommended release (and what my Linux >distribution packages). So, the only fix then is to install setuptools >from SVN HEAD? It would appear so; I guess I'm wrong about this being in 0.6c6; I just looked at my checkout, which is actually an 0.6c7dev version. Use "easy_install setuptools==dev06" to get the same version as I'm using.

1 0

CVS/Entries.Log ignored by setuptools default CVS file-finder logic
by Jeff Shell Aug. 6, 2007

Aug. 6, 2007

Hi. I'm trying to update our internal code to use distutils/setuptools at long last. We work heavily in Zope 3, so our packages contain many "data" files (ZCML, Page Templates, Javascript, CSS, etc). All of our internal code is maintained in CVS. I noticed that using ``include_package_data = True`` was having little or no effect: at most, only data files in the root directory might be included. This seems to be related to our directories being listed in `CVS/Entries.Log` instead of `CVS/Entries`, and setuptools doesn't read this file. I don't know why our directories are in this file: these are fresh checkouts (retrieved over the network using :ext: and SSH) with no local changes having yet been applied. Apparently programs that are reading 'Entries' should also read 'Entries.Log', which is slightly different from Entries. I have more details below. Is there any particular reason why this file isn't being read? I'd be surprised if I'm the only one encountering this issue. A basic fix appears to be easy: add another `re_finder` for `CVS/Entries.Log` with a regex like ``^A\s\w?/([^/]+)/``. I'm sure I could add something like this with an entry-point and our own egg, but it seems ridiculously small for us to maintain internally. Details ======= I traced this issue down to setuptools/command/sdist.py and the default set of finders:: finders = [ (convert_path('CVS/Entries'), re_finder(re.compile(r"^\w?/([^/]+)/", re.M))), (convert_path('.svn/entries'), entries_finder), (convert_path('.svn/dir-props'), externals_finder), (convert_path('.svn/dir-prop-base'), externals_finder), # svn 1.4 ] That looked right to me. Then I looked in a CVS directory in a couple of different packages and looked at Entries:: CVS> cat Entries /__init__.py/1.1/Thu Aug 18 23:29:21 2005//Tfixup-branch /addhelp.py/1.1.2.2/Wed Dec 20 22:55:09 2006//Tfixup-branch /configure.zcml/1.5.2.10/Wed Jul 18 19:32:51 2007//Tfixup-branch # .... (more lines - no directories) /tests.py/1.1.2.2/Thu Jan 18 22:10:50 2007//Tfixup-branch /traversing.py/1.1.2.2/Tue Mar 20 23:29:36 2007//Tfixup-branch /valuelib.py/1.1.2.3/Fri Jul 27 20:26:38 2007//Tfixup-branch D Hmmm, no directories... Then I noticed an "Entries.Log" file. I looked at that:: CVS> cat Entries.Log A D/authentication//// A D/batching//// # ... (more lines, all directories, all lines beginning with ``A D``) A D/undo//// Whoa! Here are all of the directories! I'm not sure why these are in there - this is showing up in a fresh code checkout, and it's showing up regardless of whether the checked out code is a branch or not. This is showing up on Mac OS X with the CVS that comes with the development tools package. CVS> cvs --version Concurrent Versions System (CVS) 1.11.18 (client/server) Our server has ``1.11.1p1``. I don't know if these version numbers mean anything in relation to this issue. Does anybody else? Anyways, the CVS manual says this about Entries.Log:: > Programs which are reading the 'Entries' file should also check > for 'Entries.Log'...The format of a line in 'Entries.Log' is > a single character command followed by a space followed by a line in > the format specified for a line in 'Entries'. The single character > command is 'A' to indicate that the entry is being added, 'R' > to indicate that the entry is being removed, or any other character to > indicate that the entire line in 'Entries.Log' should be silently > ignored (for future expansion). http://www.network-theory.co.uk/docs/cvsmanual/Workingdirectorystorage.html So, it looks like a decent solution would be to add another `re_finder` in setuptools' `sdist.py` module as mentioned above that took the Entries.Log file and format into account.... Yes? Thanks, Jeff Shell

1 0

bug in svn detection
by Keith Dart Aug. 5, 2007

Aug. 5, 2007

Greetings. I would like to report a bug in setuptools here, since I can't find a bug tracking system for it anywhere. 598 $ sudo python setup.py install running install running bdist_egg exceptions.ValueError : max() arg is an empty sequence > /usr/lib/python2.4/site-packages/setuptools/command/egg_info.py(224) in get_svn_revision() localrev = max([int(d[9]) for d in data if len(d)>9 and d[9]]) Debug:15/15> l 214 continue # no sense walking uncontrolled subdirs 215 dirs.remove('.svn') 216 f = open(os.path.join(base,'.svn','entries')) 217 data = f.read() 218 f.close() 219 220 if data.startswith('8'): 221 data = map(str.splitlines,data.split('\n\x0c\n')) 222 del data[0][0] # get rid of the '8' 223 dirurl = data[0][3] 224 -> localrev = max([int(d[9]) for d in data if len(d)>9 and d[9]]) 225 elif data.startswith('<?xml'): 226 dirurl = urlre.search(data).group(1) # get repository URL 227 localrev = max([int(m.group(1)) for m in revre.finditer(data)]) 228 else: 229 log.warn("unrecognized .svn/entries format; skipping %s", base) 230 dirs[:] = [] 231 continue 232 if base==os.curdir: 233 base_url = dirurl+'/' # save the root url 234 elif not dirurl.startswith(base_url): Debug:15/15> show get_svn_revision ( self = <setuptools.command.egg_info.egg_info instance at 0xb7b43f2c>, ) Compiled locals: files = ['mkpydocindex'] revre = <_sre.SRE_Pattern object at 0xb7cf4458> base_url = 'https://pycopia.googlecode.com/svn/trunk/vim/' localrev = 11 revision = 53 dirs = [] base = './bin' data = [['', 'dir', '0', 'https://pycopia.googlecode.com/svn/trunk/vim/bin', 'https://pycopia.googlecode.com/svn', 'add', ...], ['mkpydocindex', 'file', '', '', '', 'add', ...], []] d = [] f = <closed file './bin/.sv... mode 'r' at 0xb7c81530> m = '*** undefined ***' _[1] = '*** undefined ***' dirurl = 'https://pycopia.googlecode.com/svn/trunk/vim/bin' urlre = <_sre.SRE_Pattern object at 0xb7ba49a0> 601 !$ svn --version svn, version 1.4.4 (r25188) compiled Jun 29 2007, 12:11:09 (However, the repository may have been created with an older version of subversion). I guess Phillip would be most interested in this: 51900 phillip.eby 51900 phillip.eby if data.startswith('8'): 51900 phillip.eby data = map(str.splitlines,data.split('\n\x0c\n')) 51900 phillip.eby del data[0][0] # get rid of the '8' 51900 phillip.eby dirurl = data[0][3] 56277 phillip.eby localrev = max([int(d[9]) for d in data if len(d)>9 and d[9]]+[0]) 51900 phillip.eby elif data.startswith('<?xml'): 51900 phillip.eby dirurl = urlre.search(data).group(1) # get repository URL 56277 phillip.eby localrev = max([int(m.group(1)) for m in revre.finditer(data)]+[0]) 51900 phillip.eby else: 52009 phillip.eby log.warn("unrecognized .svn/entries format; skipping %s", base) 51900 phillip.eby dirs[:] = [] 51900 phillip.eby continue -- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Keith Dart <keith(a)dartworks.biz> public key: ID: 19017044 <http://www.dartworks.biz/> =====================================================================

2 1

Best practices on distributing documentation and examples with eggs?
by Stanley A. Klein Aug. 2, 2007

Aug. 2, 2007

On Thu, July 26, 2007 9:50 pm, Phillip J. Eby wrote: >At 02:13 PM 7/26/2007 -0500, Dave Peterson wrote: >>In further discussions at Enthought, we're now thinking that creating a 'docs' dir as a top-level under python itself makes sense, and then the installation of eggs could copy docs and/or examples there in a manner similar to how it handles scripts into the platforms scripts dir. It would make sense that they should be put in dirs named with a format like <project name>-<version> so that the user could differentiate the docs for each project they installed. If this was done, it seems like it wouldn't be too hard for Stan, and other rpm builders, to either create symbolic links or copy these to /usr/share/doc in order to maintain compatibility with the LSB. >This isn't a bad idea, although I think that there are some hurdles that need to be worked out. My general thought is that, were >easy_install to support documentation, it would need to take an >option to determine the documentation base directory, and have a --no-docs install option. >One issue is that under most RPM systems, package names are more like 'python-foobar-1.2', and 'foobar' may not even be the exact distutils name of the package. So, installing the docs to the correct location in the general case may be more complex. Note, however, that >bdist_rpm offers a --doc-files option, which of course can be >configured via setup.cfg. I have no idea how it works, though, so don't ask me. :) The practice of changing the name of the whatever package to python-whatever may be distro dependent. Also (thankfully), python-whatever is installed in site-packages/whatever and not in site-packages/python-whatever. It was not always that way. Back at something like RedHat 7, they did change the names and the installation locations. If you had another program that imported the package, you sometimes had to go in and change the code to match their changed name. I can understand the reasons of the distros and repositories for doing this (keeping all the python or other language packages together in the list) but that does not make it less annoying. In looking to see if a package is in the repository, you have to look in various places beyond what the original developer/maintainer of the package calls it. Also, I'm not sure of the split between /usr/share/whatever and usr/share/doc/whatever for things like docs, tests, examples, and other miscellaneous files. It tends to be at the whim of the packager. In terms of what bdist_rpm does, it seems to be in the preparation of the rpm spec file. The spec file contains scripts (some of which point to macros in /usr/lib/rpm/macros on a Fedora system) and bdist_rpm seems to build the scripts and execute them using rpm-build. The build and install scripts do "python setup.py build" or "python setup.py install" with whatever options are specified. I think the actual location of the files may be governed by the %files section of the spec, but I will have to spend some time looking at other spec files to be sure that is where it happens. Stan Klein

1 0

Best practices on distributing documentation and examples with eggs?
by Dave Peterson Aug. 1, 2007

Aug. 1, 2007

Over on the enthought-dev mailing list we're having a bit of a discussion on what the best way to distribute documenation and examples is for projects that we distribute binary eggs for. The general consensus is that it would be very nice indeed if there was a way to generate a tarball, or platform install, of just documentation and examples so that people wouldn't need to download a full, presumably significantly larger, source tarball. Another option would be that eggs included the documentation and examples and that, during the installation of the egg, those docs and examples were relocated to a common location (outside of the zip) to make access by users more convenient. This latter idea is similar to how Ruby Gems deal with docs. I don't claim to be a distutils or setuptools guru, so it shouldn't be too surprising that I can't seem to find anything about a setuptools or distutils command to do either of these. Am I missing something? If not, does it seem like something that might be worthy of putting into setuptools? -- Dave

5 9