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
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:
but when I try and do the step of the following:
# CXX=$mips_linux_path\g++ \
./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,
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
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
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?
Sharky @ PTNet
I am having difficulty getting disutils to build C extensions using the
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
The result was the following compiler errors:
E:\RESEARCH\Modeling\PythonFiles\SWIG test>python setup.py build -c mingw32
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
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
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
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...
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.
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:
(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.)
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:
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.
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
(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!)
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
>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:
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.
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.)
Katrina Benefit Concerts: http://www.musi-cal.com/katrina