At 11:09 PM 8/24/2009 +0200, Nicolas Dumazet wrote:
>Hello! I am the maintainer of a small C extension, and after
>uploading it to pypi, out of curiosity, I tried installing it using
>easy_install. The error that easy_install returns is however quite
>cryptic, and I have no idea of what is happening: $ easy_install -v
>-n --install-dir /Users/junk/py-lib pyfsevents
easy_install -eb. pyfsevents
python -c "import setuptools; execfile('setup.py')" bdist_egg
This will leave the build directories in place, and may give you
better error information about the problem.
>Checking existing site.py in /Users/junk/py-lib Searching for
>pyfsevents Reading http://pypi.python.org/simple/pyfsevents/ Reading
>http://bitbucket.org/nicdumz/fsevents/ Found link:
>Best match: pyfsevents 0.1 Downloading
>Validating md5 checksum for
>pyfsevents-0.1.tar.gz Unpacking pyfsevents-0.1// to
>pyfsevents-0.1/BUGS to /tmp/easy_install-NGokgY/pyfsevents-0.1/BUGS
>Unpacking pyfsevents-0.1/examples// to
>Unpacking pyfsevents-0.1/examples/testwatcher.py to
>Unpacking pyfsevents-0.1/examples/watcher.py to
>Unpacking pyfsevents-0.1/examples/watcher.pyc to
>Unpacking pyfsevents-0.1/INSTALL to
>pyfsevents-0.1/setup.py -n bdist_egg --dist-dir
>bdist_egg running egg_info creating pyfsevents.egg-info writing
>pyfsevents.egg-info/PKG-INFO writing top-level names to
>pyfsevents.egg-info/top_level.txt writing dependency_links to
>pyfsevents.egg-info/dependency_links.txt writing manifest file
>'pyfsevents.egg-info/SOURCES.txt' writing manifest file
>'pyfsevents.egg-info/SOURCES.txt' installing library code to
>build/bdist.macosx-10.5-i386/egg running install_lib running
>build_ext building 'pyfsevents' extension creating build creating
>build/temp.macosx-10.5-i386-2.5 gcc -fno-strict-aliasing
>-Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common
>-dynamic -DNDEBUG -g -Os -Wall -Wstrict-prototypes -DMACOSX
>-I/usr/include/ffi -DENABLE_DTRACE -arch i386 -arch ppc -pipe
>-c pyfsevents.c -o build/temp.macosx-10.5-i386-2.5/pyfsevents.o
>creating build/lib.macosx-10.5-i386-2.5 gcc -Wl,-F. -bundle
>-undefined dynamic_lookup -arch i386 -arch ppc
>CoreFoundation -framework CoreServices creating
>build/bdist.macosx-10.5-i386/egg/EGG-INFO zip_safe flag not set;
>analyzing archive contents... error: Setup script exited with error:
>build/bdist.macosx-10.5-i386/egg/EGG-INFO/zip-safe: No such file or
>directory Do we have a bug? Or simply a badly worded message? Note
>that I did not expect easy_install to work out of the box without
>configuration on my end, I am just surprised by the opaque error.
>Troubleshooting the issue seems quite difficult. Even with
>--build-directory , that build/bdist* repertory is not kept after
>the error. Maybe -k should be passed to setup.py when -b is passed
>to easy_install? Thanks, -- Nicolas Dumazet NicDumZ
>maillist - Distutils-SIG(a)python.org
Dne 20.8.2009 21:52, Brett Cannon napsal(a):
> 2009/8/20 Jan Matejek <jan.matejek(a)novell.com>:
>> Dne 20.8.2009 11:47, Matthias Klose napsal(a):
>>> On 14.08.2009 10:02, Tarek Ziadé wrote:
>>>> On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon<brett(a)python.org> wrote:
>>>>> On Thu, Aug 13, 2009 at 11:23, Jan Matejek<jan.matejek(a)novell.com>
>>>> Among the proposals you have detailed, the sharedir way seems like the
>>>> most simple/interesting
>>>> one (depending on you answer to Brett's question )
>>> The approach of splitting the installation into two different locations
>>> seems to be wrong, it changes the semantics for imports of python
>>> packages which are not installed in the same location. Simplest counter
>>> example is the use of relative imports, which will fail if the imported
>>> module/extension is not found in the same paths.
>> isn't using relative imports outside packages a bad practice?
> You actually can't do relative imports outside of packages; Python
> won't allow it.
all the better
>> I'm not proposing to split installation of single package. I'm proposing
>> having two different default install locations, based on package type
>> (platform dependent/independent), not on file type.
>> Package is pure (platform independent) as long as -all- of its files are
>> I have seen one problem so far: wxGTK's python part installs a .pth file
>> along with its purelib part, that supposedly points to its platlib
>> package. That of course breaks when purelib != platlib.
> But aren't you suggesting that something like wxGTK that is impure not
> be installed in two separate locations, meaning the .pth file will
> work fine?
Situation with wxGTK is such that it contains two separate packages -
one is pure, but installs the .pth. Other is impure and apparently needs
the .pth to be enabled. That's what i consider a bug, because it relies
on all packages being installed into the same location.
>> So far i would
>> consider this a bug in wxGTK, or rather relying on behavior that is not
>> well defined. But i admit that i'm not sure.
> I would argue it is well defined. When you install a package all of
> its files end up in a single directory, letting you make assumptions
> that a .pth file will be relative to all files you have installed.
>>> Other languages like Perl or Java don't have relative imports, or they
>>> map all components on the "path" into one logical path so you don't have
>>> this kind of problem.
>> and that's probably why perl approach would fail miserably in python ;)
>> unless we implemented mapping to one path. Hopefully, we probably don't
>> need to do it.
> Not sure what you mean by "mapping to one path". Are you saying Perl
> basically treats all directories on its path as if it was one big
> directory? If so Python already does that with sys.path (but with a
> defined order). But as soon as you end up in a package that goes away
> as __path__ takes over (although that can be changed and is the reason
> pkgutil exists).
As you're saying. Relative imports break the abstraction. In order to
implement the "perl approach", i.e. splitting by pure/impure files
instead of packages, we would need relative imports to support this.
But this is all just theoretical. As there doesn't seem to be any
compelling argument to go this way, let's stick with what works now.
On Fri, 21 Aug 2009 08:05:47 -0700, Martin v. Löwis <martin(a)v.loewis.de>
> It might also be useful to have a
> distutils command that generates a pypi-like page, so that people can
> preview the rendered description.
I often think: why not integrate Sphinx with PyPI's web page generation?
Perhaps a sphinx extension that would generate the "front page" for PyPI
containing long_description and download links along with other pertinent
metadata. Then, this "preview" functionality can be flexibly added to
distutils (which would delegate to Sphinx anyway).
Additionally, the entire documentation can also be attached to a PyPI
page, for instance:
http://pypi.python.org/pypi/Distribute would be the "front page"
http://pypi.python.org/pypi/Distribute/docs/api can be the api docs
The same URL structure can be made available in the local preview
<radical/crazy thinking>Hmm, why not merge bitbucket and PyPI (w/ sphinx,
Distribute)? One stop Python development!
I am the maintainer of a small C extension, and after uploading it to
pypi, out of curiosity, I tried installing it using easy_install.
The error that easy_install returns is however quite cryptic, and I
have no idea of what is happening:
$ easy_install -v -n --install-dir /Users/junk/py-lib pyfsevents
Checking existing site.py in /Users/junk/py-lib
Searching for pyfsevents
Found link: http://pypi.python.org/packages/source/p/pyfsevents/pyfsevents-0.1.tar.gz#m…
Best match: pyfsevents 0.1
Validating md5 checksum for /tmp/easy_install-NGokgY/pyfsevents-0.1.tar.gz
Unpacking pyfsevents-0.1// to /tmp/easy_install-NGokgY/pyfsevents-0.1/
Unpacking pyfsevents-0.1/BUGS to /tmp/easy_install-NGokgY/pyfsevents-0.1/BUGS
Unpacking pyfsevents-0.1/examples// to
Unpacking pyfsevents-0.1/examples/proofofconcept.py to
Unpacking pyfsevents-0.1/examples/testwatcher.py to
Unpacking pyfsevents-0.1/examples/watcher.py to
Unpacking pyfsevents-0.1/examples/watcher.pyc to
Unpacking pyfsevents-0.1/INSTALL to
Unpacking pyfsevents-0.1/LICENSE to
Unpacking pyfsevents-0.1/PKG-INFO to
Unpacking pyfsevents-0.1/pyfsevents.c to
Unpacking pyfsevents-0.1/README to
Unpacking pyfsevents-0.1/readme.rst to
Unpacking pyfsevents-0.1/setup.py to
Running pyfsevents-0.1/setup.py -n bdist_egg --dist-dir
writing top-level names to pyfsevents.egg-info/top_level.txt
writing dependency_links to pyfsevents.egg-info/dependency_links.txt
writing manifest file 'pyfsevents.egg-info/SOURCES.txt'
writing manifest file 'pyfsevents.egg-info/SOURCES.txt'
installing library code to build/bdist.macosx-10.5-i386/egg
building 'pyfsevents' extension
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -Os -Wall
-Wstrict-prototypes -DMACOSX -I/usr/include/ffi -DENABLE_DTRACE -arch
i386 -arch ppc -pipe
-c pyfsevents.c -o build/temp.macosx-10.5-i386-2.5/pyfsevents.o
gcc -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc
build/lib.macosx-10.5-i386-2.5/pyfsevents.so -framework CoreFoundation
zip_safe flag not set; analyzing archive contents...
error: Setup script exited with error:
build/bdist.macosx-10.5-i386/egg/EGG-INFO/zip-safe: No such file or
Do we have a bug? Or simply a badly worded message?
Note that I did not expect easy_install to work out of the box without
configuration on my end, I am just surprised by the opaque error.
Troubleshooting the issue seems quite difficult. Even with
--build-directory , that build/bdist* repertory is not kept after the
error. Maybe -k should be passed to setup.py when -b is passed to
Nicolas Dumazet — NicDumZ
Basically, I can install files into:
(or anywhere in xdg.BaseDirectory.xdg_data_dirs really)
but I want to pick the most appropriate place, taking into account the
--prefix option to setup.py, or the root of the virtualenv/whatever.
What is the most portable way to to this?
Please take a look at issue #2 - http://bugs.python.org/setuptools/issue2
It's very old, it has a patch that was tested and is marked and
considered critical by several users (7) and still nobody take time to
include the patch in svn.
If nobody can commit this I would like to request a svn account so I
would be able to repair this issue.
---------- Forwarded message ----------
From: Jules Stevenson <setuptools(a)bugs.python.org>
Date: Fri, Aug 21, 2009 at 12:48 PM
Subject: [issue2] easy_install broken on 64 bits Windows
To: asmodai(a)in-nomine.org, jaraco(a)jaraco.com, jules(a)js3d.co.uk,
Jules Stevenson <jules(a)js3d.co.uk> added the comment:
I'm having no joy installing the patch [my knowledge of this is practically
non-existent]. Is there any chance that anyone could host the patched source so
I can get hold of it? Aprreciate this is a big ask. My email is jules at
js3d.co.uk. many thanks.
Setuptools tracker <setuptools(a)bugs.python.org>
On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon<brett(a)python.org> wrote:
> On Thu, Aug 13, 2009 at 11:23, Jan Matejek <jan.matejek(a)novell.com> wrote:
>> I'm cross-posting this to distributions@freedesktop and python-dev,
>> because the topic is relevant to both groups and should be solved in
>> The issue:
>> In Python's default configuration (on linux), both purelib (location for
>> pure python modules) and platlib (location for platform-dependent binary
>> extensions) point to $prefix/lib/pythonX.Y/site-packages.
>> That is no good for two main reasons.
>> One, python depends on the "lib" directory. (from distro's point of
>> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
>> impossible to install python under /usr/lib64 without heavy patching.
>> Repeated attempts to bring python developers to acknowledge and rectify
>> the situation have all failed (common argument here is "that would mean
>> redesign of distutils and huge parts of whatnot").
> This is now Tarek's call, so this may or may not have changed in terms of
> what the (now) distutils maintainer thinks.
I don't recall those repeated attempts , but I've been around for less
than two years.
You are very welcome to come in the Distutils-SIG ML to discuss these matters.
I'm moving the discussion there.
Among the proposals you have detailed, the sharedir way seems like the
one (depending on you answer to Brett's question )
Tarek Ziadé | http://ziade.org
(Under Python 2.6) I'm trying to get an MSI installer together for a
small python program. I've written a postinst script that basically
creates a shortcut on the desktop (unfortunately I couldn't see a more
agnostic way to do this, but oh well). It works with a "bdist_wininst"
type build, but not with a "bdist_msi" build. It looks like a console
pops up for a tenth of a second, and depending on what fails there's a
GUI error dialog suggesting that I contact... myself... for support.
The script appears to run, but sys.argv does not contain "-install" as
I expected and none of the functions that are given in the
"bdist_wininst" docs are present.
I guess I naively presumed that the MSI build would be similar to the
wininst build, but I can't find any docs, so are there any other
resources I can look at?
At 12:28 AM 8/19/2009 -0400, Glyph Lefkowitz wrote:
>What goes in the "..." is pretty important.Â For one thing, I don't
>quite understand the implications of this approach.
Basically, anything required in the '...' will be downloaded (and
built if necessary) then dropped into the setup.py directory as an
.egg file or directory, unless of course a suitable version of that
dependency is already on sys.path (or was already downloaded during a
previous run). They will not necessarily be included at install
time, but will be available during the remainder of the setup.py execution.
It occurs to me that there is some possibility that if a given
library is both a build-time and install-time dependency, that it
might not be installed correctly in the case of a "setup.py install"
(as opposed to an "easy_install whatever") use case. (But if so, then
it's an existing bug in setuptools that should be fixed anyway, and
is not specific to this way of invoking a build-time dependency.)
I have a recurring problem with distutils/setuptools/Distribute,
which is that I don't know how to extend the functionality of
setup.py and make the new functionality be testable and modular.
Here's one specific example that I currently have a lot of experience
with: I'd like to generate a version number from revision control
history. Don't get hung up on the desired functionality though -- if
you think that generating version numbers is best done a different
way, or if you don't care about generating version numbers, then
please just mentally insert some other extension of your build
functionality that you do care about.
I'm familiar with three different ways to implement an extension like
The first is what Nevow does , which is to write in setup.py "from
nevow import __version__". Well, this works in the case that
setup.py is being executed as the command-line script in a fresh,
empty Python interpreter, but it fails in the case that the Python
interpreter has already been running for a while, has already
imported nevow (a *different* nevow from a different location on the
local filesystem), and is now importing *this* nevow's setup module
in order to build this nevow. This happens with setuptools and
py2exe. Distribute v0.6 includes a patch  to fix this, but I'm
not sure the patch is right (it involves 'for m in various_modules:
del sys.modules[m]' and it doesn't seem to fix all cases). PJE says
"Thou shalt not import yourself when trying to build yourself" .
Glyph says "Then how do I test this code?" . I say "Ugh, I don't
know. Let's look at the other two ways to do it."
The second is what I do in some of my packages such as pycryptopp
. Just take that functionality that you want to add to all of your
packages and cut and paste the code into each of your setup.py's,
then edit it a little to reflect the correct name of the current
package. This sucks because you're cutting and pasting code, because
your setup.py gets bigger and hairier the more functionality your
build system has, and because, again, you can't test it.
The third is what I do in Tahoe-LAFS . I moved the functionality
in question into a separate Python package, in this case named
"darcsver" , and used setuptools's plugin system to add a command
named "darcsver" which initializes the distribution.metadata.version
attribute correctly. Then I had to add a bunch of aliases to my
setup.cfg  saying "If you're going to build, first darcsver, and
if you're going to install, first darcsver, and ...". This sort of
works, except that yesterday my programming partner Brian Warner
informed me  that he expected the "python ./setup.py --version"
command-line to output the version number. Argh! There is no way to
configure in my setup.cfg "If you're going to --version, first
So it appears to me that none of these techniques are both modular/
testable and compatible with distutils/setuptools/Distribute. What
are we to do?