Distutils-SIG August 2008

distutils-sig@python.org

40 participants
81 discussions

Do end-users need to install Python before installing/using Python extentions for a Windows program?

by SrMandrake ElMago

Hello, I have developed a little Windows program that uses Python extensions I wrote myself (no SWIG or nothing), and I was wondering, if I am going to make this program run in a machine Windows, do I have to actually install Python in this machine, if not, what are the minimum requirements. Thanks in advance Rod-

11 years, 11 months

[issue38] bdist_egg extension stub loaders are broken

by Philip Jenvey

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> _______________________________________________

11 years, 11 months

[issue37] del __loader__ causes problems in appengine

by Ian Bicking

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> _______________________________________________

11 years, 11 months

[issue36] warning about "module was already imported from"

by Zooko O'Whielacronx

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> _______________________________________________

11 years, 11 months

versions and forward referencing options in recipe eggs

by Matt Halstead

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

11 years, 11 months

Testers wanted: about a dozen setuptools bugs closed in trunk

by Phillip J. Eby

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!

11 years, 11 months

Setuptools download cache

by David Turner

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.

11 years, 11 months

Re: [Distutils] Question about finding downloads (with distutils.cfg)

by Phillip J. Eby

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.

11 years, 11 months

embedding eggs into .msi (or another installer)

by Hartmut Goebel

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

11 years, 11 months

Re: [Distutils] [ANN] EggFreezer

by Ian Bicking

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

11 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG August 2008