Mailman 3 December 2005 - Distutils-SIG

python port for openwrt
by nic 08 Dec '05

08 Dec '05

Hi Tim, I'm trying to get a cut down version of the python interpreter running under openwrt. I saw you message on the python mailing list from 2004 and was wondering if you could let me know more about how you compiled it. Could you send me the make file you used or some cut and pastes of the commands you ran. I'm new to cross compilation and a bit green. I'm also trying to get the size down of the interpreter. I only need to run a few scripts which don't need that many modules, in the scripts they just import serial, sys, time, string, cStringIO, and struct. Did you ever just make a interpreter that included a sub set of the modules? I've been following the basic idea of compiling then renaming two exe python and pgen and so you have the two exes that will run on the native machine which is the tricky part from what people say. I've tried following the description that you link to in your post: http://www.ailis.de/~k/docs/crosscompiling/python.php but when I try and do the step of the following: # CXX=$mips_linux_path\g++ \ CC=$mips_linux_path\gcc \ AR=$mips_linux_path\ar \ RANLIB=$mips_linux_path\ranlib \ ./configure mips_linux --target=mips_linux --prefix=/usr I get errors from the ./configure step saying it that g++ can not create executables. I guess it's trying to build an executable on my desktop with the cross compiler g++ and then seeing that it doesn't work on the desktop and then complaining, how did you get around this? Any help would be really appreciated. Thanks a bunch, Nic

1 0

A distutils question
by Noel O'Boyle 08 Dec '05

08 Dec '05

It's true (see thread below) - I have been scared away from asking questions about distutils. But here I go... Can someone help me. I think this is quite a common problem but there doesn't appear to be any obvious answer: Can someone suggest how I can write a setup.py for a pure-Python application that should install on both Linux and Windows? The application includes a startup script, a package, and some data files (or package data) referred to by some modules in the package. The Linux version will be distributed as a source distribution. The Windows version will be distributed as a bdist_wininst, and should create a shortcut in the Start Menu folder. An answer will not only receive my heartfelt thanks, but be posted on the web (http://www.redbrick.dcu.ie/~noel/distutils), so that others will not have the same problem. A method that will work for both Python 2.3 and 2.4 would be the most appreciated. ---------contents of development directory setup.py README MANIFEST.in license.txt src/ startupscript.py mypkg/ __init__.py module_a.py help.html images/ shamrock.png Regards, Noel On Wed, 2005-12-07 at 14:22 -0500, Stephen Langer wrote: > On Dec 7, 2005, at 12:10 PM, Ian Bicking wrote: > > > Kevin Dangoor wrote: > >> -1 > >> > >> In the months that I've been subscribed to this list, I haven't > >> really > >> seen any *other* discussion that seems geared towards improving > >> distribution of Python modules and add-ons. > > > > Ditto. Setuptools is the most active distutils-related development > > right now, no surprise there's lots of messages on it. The volume > > is a > > *good* thing ;) > > I guess the concern is that the dominance of setuptools message is > scaring away people with old-fashioned distutils questions. There > haven't been many of those lately, and some of them seem to have > received no response. I don't think that splitting the list in two > is a solution, though. There's not enough traffic to warrant that > (except for a brief spurt a week or so ago...) > > -- Steve >

3 2

easy_install trac
by Sharky On PTNet 07 Dec '05

07 Dec '05

Hi, I need some help to install trac (http://www.python.org/pypi/trac/0.9) with easy_install. My problem is that trac have modules to instal in python/site-packages/, have scripts to install in /usr/bin/ and have files to install in /usr/share/trac. Any one can tell me how to do this with easy_install? Many Thanks, Helio Pereira Sharky @ PTNet

2 1

trouble building C extensions with mingw
by mike cantor 07 Dec '05

07 Dec '05

I am having difficulty getting disutils to build C extensions using the mingw compiler. After installing mingw (file: MinGW-4.1.0.exe) I followed the instructions described in http://sebsauvage.net/python/mingw.html, using pexports and dlltool as instructed and placing libpython23.a the python installation directory. As was noted in this page, disutils did not have to be tweaked. I then copied example.c and example.i and setup.py to the same folder and from within that directory in a dos prompt ran "python setup.py build -cmingw32 " The result was the following compiler errors: E:\RESEARCH\Modeling\PythonFiles\SWIG test>python setup.py build -c mingw32 running build running build_ext building 'example' extension swigging example.i to example_wrap.c E:\swigwin-1.3.27\swig.exe -python -o example_wrap.c example.i C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IE:\Python23\include -IE:\Pytho n23\PC -c example_wrap.c -o build\temp.win32-2.3\Release\example_wrap.o example_wrap.c: In function `_wrap_My_variable_set': example_wrap.c:1621: error: `My_variable' undeclared (first use in this function ) example_wrap.c:1621: error: (Each undeclared identifier is reported only once example_wrap.c:1621: error: for each function it appears in.) example_wrap.c: In function `_wrap_My_variable_get': example_wrap.c:1631: error: `My_variable' undeclared (first use in this function ) example_wrap.c: In function `_wrap_fact': example_wrap.c:1648: warning: implicit declaration of function `fact' example_wrap.c: In function `_wrap_my_mod': example_wrap.c:1676: warning: implicit declaration of function `my_mod' example_wrap.c: In function `_wrap_get_time': example_wrap.c:1692: warning: implicit declaration of function `get_time' error: command 'gcc' failed with exit status 1 Can anyone tell me where to go from here? I have been trying to get this to work for three days now... Thanks, -mike

2 1

Re: [Distutils] setuptools site-package pollution
by Phillip J. Eby 07 Dec '05

07 Dec '05

At 11:07 AM 12/7/2005 +0100, Anthony Tarlano wrote: >Maybe it is just a pet-peeve, but I like to keep a nice tidy >site-packages directory, and these long directory names just seem to >me to be pollution of my site-packages directory in my command shell. The purpose is to allow easy removal or upgrade of packages. The normal distutils installation process has no provision for uninstallation or the deletion of obsolete modules when a package is upgraded. Putting each package in its own versioned subdirectory allows comparatively trivial uninstallation and upgrades. This is particularly important if you are using packages that are not provided by a system package manager (e.g. an RPM or Debian, etc.) For example, during the development of PyProtocols, there have been times where I've deleted or renamed a module. Using the standard distutils installation, this would sometimes result in people's upgrades still having the old modules present. In short, the standard distutils installation process is not manageable without wrapping in some kind of package management tool like bdist_rpm or bdist_wininst. >If there is an option to have just the packages, I would really >appreciate someone telling me what it is. If not maybe it could be >considered, and to put whatever meta-data the directory names are >providing somewhere else.. There is an --old-and-unmanageable option to the "setup.py install" command which will install setuptools-based packages the old and, yes, unmanageable way. It does not work with packages that require the additional metadata - such as setuptools itself. It should be able to be used with RuleDispatch and PyProtocols, at least for the moment. It will *not* work if you try to install packages that declare dependencies on those packages. For example, if you install RuleDispatch using --old-and-unmanageable, then TurboGears will try to reinstall it and warn you about conflicting packages installed the old and unmanageable way in site-packages. There is another option I'm working on, --single-version-externally-managed, which is designed for system packagers to create old-style packages, but with the metadata included as a separate .egg-info directory. This won't help you, though, because it will result in having even *more* directories in site-packages - the package directories plus an .egg-info directory. Anyway, this approach will be used for future setuptools integration with bdist_rpm, bdist_wininst, etc., since these package management tools are able to handle safe upgrades and uninstallation in a way that the unadorned distutils install process cannot.

2 1

Setuptools version parsing changed in SVN
by Phillip J. Eby 06 Dec '05

06 Dec '05

FYI, I've changed the setuptools version parsing scheme. The release of a 'Subway 0.2-rc1' today made it clear that the existing scheme was unintuitive in how it handled '-' characters, because people expect the '-' not to override the 'rc'-ness. In all previous versions of setuptools, a '-' always meant "this is a post-release patch of the thing before the dash". As of 0.6a9-r41630, however, the '-' is ignored when it comes before a prerelease tag like 'rc' or 'b' or 'dev', so that the intuitively-expected behavior holds. This should also fix the existing issues with CherryPy 2.1.0-rc2 and similar releases out there. I've also updated the setuptools doc page with a section on specifying your project's version number: http://peak.telecommunity.com/DevCenter/setuptools#specifying%2Dyour%2Dproj… (The advice given there will work for all versions of setuptools, as it is based on the less-forgiving algorithm that's already out there.)

1 0

Preliminary support for .egg-info files in Subversion
by Phillip J. Eby 06 Dec '05

06 Dec '05

I've just added experimental preliminary support for the .egg-info file convention in Subversion. It makes the assumption that an .egg-info file will contain the standard distutils "PKG-INFO" data, that the distutils generate for source distributions and that existing egg formats include as an EGG-INFO/PKG-INFO or .egg-info/PKG-INFO file. (It still recognizes .egg-info directories, of course.) I haven't yet added support for installing an egg in this format; I've been under other deadline pressure and this is the first I've gotten to work on this in a couple of weeks. I wanted to go ahead and get this basic capability out there so that people porting e.g. TurboGears could go ahead and make some progress by manually creating .egg-info files. Please let me know (via the distutils-sig list) if you have any issues. Issues with the *implementation*, that is, not the idea of having .egg-info files. I'm already aware that it's somewhat controversial to some. ;) The setuptools patch is at: http://svn.python.org/view?view=rev&rev=41615 And you can fetch the latest source into a 'setuptools' directory, ready for patching, by using: easy_install -eb. setuptools==dev (The -e means "fetch an editable source version and unpack it", the -b. means to do so in the current directory.) Or you can just use a direct Subversion checkout. (I don't build binary eggs for interim releases.) Note that if you build a setuptools egg from this version, its version number (as expressed in its filename or .egg-info filename) should be '0.6a9.dev-r41615'. This will be handled automatically if you build the egg with setuptools, but if you're creating an .egg-info directory in order to flatten it, you'll want to make sure you keep the same version information as the original. I'll post again when the --single-version-externally-managed option to 'install' and 'easy_install' is also available.

1 0

easy_install problem.
by Titus Brown 04 Dec '05

04 Dec '05

Hi folks, it appears easy_install has trouble understanding package names with periods in them, e.g. "zope.testbrowser". Also, 'python ez_setup.py --help-commands' doesn't work; "unrecognized command". (I'm not sure where to send reports of these problems, but google found some discussion on this list, and it doesn't seem terribly inappropriate... sorry if it is!) cheers, --titus

3 9

Re: [Distutils] Trouble installing Myghty with --prefix
by Phillip J. Eby 01 Dec '05

01 Dec '05

At 11:58 AM 11/30/2005 -0600, skip(a)pobox.com wrote: > Ian> There's non-root installation instructions on the setuptools site > Ian> (and maybe included in easy_install now?) that will create a full > Ian> Python environment in a non-standard location, which would probably > Ian> resolve this issue. > >Thanks, but that's not what I'm after. On my CentOS 4 server, Python 2.3.x >is installed with /usr as the prefix (that is, I use the CentOS-provided >version of Python). I install all third-party packages (including my own >code) with a prefix of /usr/local/mojam so I can a) avoid polluting the base >package and b) install things without becoming root. Accordingly, I dump a >mojam.pth file in the system site-packages directory which contains this one >line: > > /usr/local/mojam/lib/python2.3/site-packages > >That is my only pollution of the default Python installation. I'd like to >keep it that way. Can setuptools (be made to) do the job? Yes, but you need two things: 1. Change your .pth file to read: import site; site.addsitedir('/usr/local/mojam/lib/python2.3/site-packages') 2. Create a distutils.cfg in /usr/lib/python2.3/distutils/ with the contents I mentioned before. Basically, without #1, .pth files in /usr/local/mojam/lib/python2.3/site-package won't be processed by Python, and without #2, setuptools won't know that Python is processing the .pth files.

2 4

Trouble installing Myghty with --prefix
by skip＠pobox.com 01 Dec '05

01 Dec '05

I tried installing Myghty 0.99a using this command: python setup.py install --prefix=/usr/local/mojam (e.g., non-standard install location). It downloaded setuptools and installed a bunch of other stuff (Paste, etc), all available as eggs. Unfortunately, it didn't create packages and didn't make the pkg_resources module available. Any hints about how to get this working would be appreciated. (I have no idea what other details you'll need, never having used setuptools - directly or indirectly. Let me know if there's more I can do to explain the situation.) Thx, -- Skip Montanaro Katrina Benefit Concerts: http://www.musi-cal.com/katrina skip(a)pobox.com

3 6