New submission from Philip Jenvey <pjenvey(a)underboss.org>:
There's two different stub loader generators in the code base:
build_ext.write_stub and bdist_egg.write_stub
bdist_egg's stub loader always assumes the presence of a __loader__ value, which
causes a NameError in some cases. build_ext's version of the stub loader does
the right thing and only messes with __loader__ if it exists -- the following
patch applys that check to bdist_egg's stub loader
This fix is particularly important for packages with optional C extensions
deployed to Google App Engine (like simplejson, Genshi). Compiled extensions
won't be imported by GAE (as they're not supported), so instead the stub loader
is imported. Without a __loader__ present this results in:
File "/base/data/home/apps/sluggo-exp/2.1/lib/python2.5/site-
packages/simplejson-1.8.1-py2.5-macosx-10.3-i386.egg/simplejson/_speedups.py",
line 5, in __bootstrap__
del __bootstrap__, __loader__
NameError: global name '__loader__' is not defined
instead of an ImportError, which these packages expect to be raised when they
need to fallback to the alternative to the compiled extension
This should really make it in for the next release; prioritized as critical
----------
files: bdist_egg-stub-loader_r65963.diff
messages: 149
nosy: pjenvey
priority: critical
status: unread
title: bdist_egg extension stub loaders are broken
Added file: http://bugs.python.org/setuptools/file20/bdist_egg-stub-loader_r65963.diff
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue38>
_______________________________________________
New submission from Ian Bicking <ianb(a)colorstudy.com>:
Per this thread, the placeholder .py file created by setuptools can cause
problems when it deletes __loader__: http://markmail.org/message/qy2d6awkzcrr5t5s
----------
files: loader_bdist_egg.patch
messages: 148
nosy: ianb(a)colorstudy.com
priority: bug
status: unread
title: del __loader__ causes problems in appengine
Added file: http://bugs.python.org/setuptools/file19/loader_bdist_egg.patch
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue37>
_______________________________________________
New submission from Zooko O'Whielacronx <zooko(a)zooko.com>:
/usr/lib/python2.5/site-packages/zope/__init__.py:19: UserWarning: Module
twisted was already imported from
/usr/lib/python2.5/site-packages/twisted/__init__.pyc, but
/home/buildslave/tahoe/feisty2.5/build/support/lib/python2.5/site-packages/Nevow-0.9.31-py2.5.egg
is being added to sys.path
Here is an example command line that yields this warning:
http://allmydata.org/buildbot/builders/feisty2.5/builds/1649/steps/pyflakes…
Note that this may be related to issue17 and issue20 -- why is the Nevow egg
declaring the "twisted" namespace and/or module anyway?
----------
messages: 136
nosy: zooko
priority: bug
status: unread
title: warning about "module was already imported from"
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue36>
_______________________________________________
I have stumbled over a behaviour where the versions option is ignored
in a particular scenario. I am wondering if this is intended behaviour
or not.
The following is a simple example of a not very useful buildout. (this
uses setuptools-0.6c8-py2.4 and zc.buildout-1.1.1-py2.4)
--------------
[buildout]
eggs-directory = ${buildout:directory}/eggs
download-cache = ${buildout:directory}/downloads
versions = versions
parts =
plone
instance-base-eggs =
${plone:eggs}
[versions]
plone.recipe.plone = 3.1.4
[plone]
recipe = plone.recipe.plone
------------------------
When we define instance-base-eggs explicitly like this within the
buildout section, then when the buildout bootstrap process is run
(e.g. python2.4 bootstrap.py), the latest egg for plone.recipe.plone
will be pulled and used to satisfy the recipe egg requirement when the
buildout is run. The version in the versions section is ignored here.
It is not ignored if the version is pinned directly to the
plone.recipe.plone i.e. we have
[plone]
recipe = plone.recipe.plone == 3.1.4
If instead we have the following
------------------------
[buildout]
eggs-directory = ${buildout:directory}/eggs
download-cache = ${buildout:directory}/downloads
versions = versions
parts =
plone
[base]
eggs =
${plone:eggs}
[versions]
plone.recipe.plone = 3.1.4
[plone]
recipe = plone.recipe.plone
--------------------------
Then the plone.recipe.plone egg is not pulled during the bootstrap
process, but instead during the buildout process at which point the
version pinning in the versions section is honored just fine.
Is it intended that the bootstrap process ignores versions in the
versions section?
cheers
Matt
I've checked in numerous fixes to bugs from the tracker today, with
the intention to cut a c9 release on Monday. Please update with
"easy_install setuptools==dev", and try it out. Thanks!
Attached is a patch which adds download caching to setuptools.
At TOPP (http://topp.openplans.org/), we use a system called fassembler
to build our opencore stack. It creates approximately a dozen
virtualenvs, each with their own lib/python, and then uses setuptools to
install lots of libraries. Some of these libraries are common among
multiple apps, but we install multiple copies for ease of development.
And every time we rebuild, we start the whole process over again. The
major slowdown in building is downloading a bunch of things which
probably haven't changed since last time we downloaded them. This
patch will let us maintain a cache of all downloads, and thus do builds
much faster.
Anyway, I hope you'll accept this patch.
At 05:33 PM 8/22/2008 +0100, Fadhley Salim wrote:
>All of the five sources contain the exact same collection of files.
>
>Most users who can access the european web-servers cannot access the
>American UNC paths and vice-versa.
>
>That usually works out well, because the sources a user cannot access
>will quickly time-out and the user will get the egg they need from a
>source they can access.
>
>The problem comes with users who can access both the web-servers *and*
>the UNC paths easy_install. For example a mobile, "international" user
>might have access to everything but with a slow connection.
>
>Even if the egg needed can be found on any one of the hosts the
>remaining two (the UNC paths) will always be checked by setuptools. This
>makes setuptools run very slow indeed:
>
>I have found that easy_install is needlessly checking all five sources
>even if checking only one would be good enough.
>
>Is there a way to make setuptools stop searching as soon as it's found
>the first source which contains the required egg?
Yes and no. The issue here is that easy_install sees the UNC paths
as local, so it should actually check them *first*, and then skip the
URLs if the requirements can be met. However, once easy_install has
checked even one URL, it will check any subsequent URLs immediately.
So, in theory, you could make it check the UNC paths first and not
the URLs, but you might find it difficult to lock down in
practice. Plus, it doesn't actually fix your problem, if I
understand it correctly.
Hi,
coming from Unix, I now want to be helpful to Windows-users and prepare
some installable package for one of my tools
(http://pdfposter.origo.ehtz.ch).
Since py2exe does not work in Unix and not even on wine, I'm currently
stuck with bdist_msi or bdist_wininst. This works fine so far.
Unfortunately pdfposter requires another package (pyPdf) which is
available as win32-installer.
Now the user of pdfposter would need to download and install both
packages, one by one.
I'm looking for a solution for packaging pyPdf into the same
msi/installer as pdfposter and install pyPdf if missing on the target
system.
Any hints? Any recipes?
--
Schönen Gruß - Regards
Hartmut Goebel
Dilp.-Informatiker (univ.), CISSP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Alberto Valverde wrote:
> Ian Bicking wrote:
>> Alberto Valverde wrote:
>>
>>> The usage is pretty straightforward:
>>>
>>> eggfreezer -o AllTurbogears2 -f
>>> http://turbogears.org/2.0/downloads/current TurboGears2 tg.devtools
>>>
>>> That command will try to satisfy all dependencies for TurboGears2 and
>>> tg.devtools (fetching them from local packages if available), using that
>>> url to find links, and bundle them into a file called
>>> AllTurboGears2-${py_version}-${platform}.py.
>>>
>> As long as you are doing platforms, it might be nice to get them right.
>> Specifically the UCS2/UCS4 distinction, though there might be more
>> that I'm forgetting. (If there's actually platform-dependent files in
>> there, if not it'd be nice to leave out the platform entirely.)
>>
> I'm using pkg_resources.Distribution's 'platform' attribute to get this,
> the algorithm basically iterates over all dependencies and as soon as
> one has it set to not None it'll use that. If all are set to None then
> no ${platform} is added to the filename. I'm assuming of course that all
> distributions have the same string as platform, which I guess it isn't
> not too far-fetched, but haven't really checked so I'm sure there's
> something I might have overlooked.
>
> BTW, does pkg_resources populate it properly with he UCS2/UCS4
> distinction you mention?
No... which makes binary eggs unusable on Linux. I feel like there was
something else that made binary packages on a Mac unreliable, but I
can't remember. Windows binary eggs generally work fine. This is
discussed some here:
http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-e…
One nuisance is that people don't generally know how their Python was
built (UCS2 or UCS4). I was thinking about making something very
similar to eggfreezer (which I'm unlikely to do now that eggfreezer
exists ;), and generating an "install" .py file that determines the
platform and downloads the appropriate platform bundle.
--
Ian Bicking : ianb(a)colorstudy.com : http://blog.ianbicking.org
Hi All,
I have a setup.py that looks roughly like:
import os
from setuptools import setup, find_packages
...
setup(
...
packages=find_packages(),
zip_safe=False,
include_package_data=True,
...
)
...and a file layout roughly like:
/bootstrap.py
/buildout.cfg
/setup.py
/mypackage/...
When I do setup.py sdist, the resulting .zip [1] file contains
bootstrap.py and setup.py but not buildout.cfg, even though it is in svn.
What's going wrong here?
cheers,
Chris
[1] Anyone know how to get .tgz source builds on windows rather than
.zips?
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
