Mailman 3 August 2006 - Distutils-SIG

Spurious "required version not available" error for setuptools?
by Hamish Lawson Aug. 30, 2006

Aug. 30, 2006

I have version 0.6c1 of setuptools installed, but when I try to easy_install Kid from subversion: easy_install svn://kid-templating.org/trunk I get this error message: The required version of setuptools (>=0.6a11) is not available Any pointers to why? Thanks, Hamish Lawson

1 0

Re: [Distutils] [setuptools] running a post_install script
by Rick Ratzel Aug. 24, 2006

Aug. 24, 2006

> >I've just been discovering the beauties of setuptools - for someone like > >me, developing a package with many dependencies, it could be just the > >tonic! And very easy to get going too - thnks! > > > >One question though - my package carries a post-install script to create > >a few shortcuts on windows systems. Creating an egg and then > >easy_installing it copies a setuptools version of the script to the > >scripts folder but it doesn't run at the end of install (or maybe it > >tries to and fails in some hidden way). > > easy_install doesn't support post-install scripts, currently, as it's > designed for installation of libraries rather than applications. > > It's possible that some future version of easy_install could support a > mechanism for various kinds of post-install hooks, in order to allow e.g. > shortcut registration, registry entries, and the like. The idea would be > that a package would include metadata that describes the registration info > needed, rather than including code to actually do the registration. (The > idea here being that we're not opening up for arbitrary code to run during > installation.) > > But at this point, such a feature is a rather long way off. So for now, > it's best to just instruct users how to run your postinstall script (which > ideally should be given a name that's unique to your package, e.g. > 'foo-postinstall' if your package is named foo). Here at Enthought, we're developing an application which provides a graphical user interface to easy_install which also adds additional features that we need in order to deploy some of the libraries we use in egg form. One of the additional features we need is the ability to run post-install scripts. The application is named "Enstaller" and is currently available only as an alpha right now, and only for Windows. Enstaller will eventually be used as the means for distributing "Python Enthought Edition". At the moment, the stable versions of Python Enthought Edition are distributed as a massive Wise .exe installer...Enstaller allows users to pick and choose the individual packages provided by Enthought rather than downloading several which they don't need. It also allows a user to browse and install from the Python Cheeseshop. In order to distribute the complete Python Enthought Edition in egg-form, we had to make eggs for two applications which are bundled in the big .exe file: Swig and MinGW. The post-install scripts bundled with those eggs add their dirs to the search PATH. Another egg we have is for VTK, and it's post-install script adds one of the dirs to the search PATH so it's .dlls are found. Also, our pywin32 egg has a post-install script which runs to do the various registry mods that the pywin32 .exe installer does. Currently, only Enstaller knows how to run these post-install scripts. If the egg it just installed has a "post_install.py" script in EGG-INFO, it runs it. The post_install.py script calls, in an order defined at egg-build time, the scripts in EGG-INFO/post_install. At the moment, this does allow for arbitrary code to run during install, which has the potential to be bad. We needed something to allow this given the many diverse packages we offer in Python Enthought Edition though, but I imagine future versions won't allow this and will instead be more like what Phillip suggested by only allowing specific registration operations. If you'd like to check it out, the link to the Python 2.4.3 Enthought Edition 1.1.0 download page (has a link to a Python-2.4 .exe installer which runs Enstaller at the end to add the Enthought Edition packages, as well a link to the Enstaller bootstrap script if you wish to use an existing Python 2.4 Windows install) is here: http://code.enthought.com/enthon/enstaller.shtml ...and the Enstaller wiki is here: http://enthought.com/enthought/wiki/Enstaller Remember that a.) it's still alpha and undergoing frequent changes, and b.) while it can run on other platforms, the packages it requires to get it properly bootstrapped are only available for Windows and Python 2.4...that will change soon though. Hope this helps! -- Rick Ratzel - Enthought, Inc. 515 Congress Avenue, Suite 2100 - Austin, Texas 78701 512-536-1057 x229 - Fax: 512-536-1059 http://www.enthought.com

1 0

setuptools and python-2.3.4
by krokodylek＠tenbit.pl Aug. 24, 2006

Aug. 24, 2006

Hi :-) I want to use some plugins for Trac, which come in source code and require setuptools for install. The server with Trac is running on Fedora Core 3 and has python 2.3.4 (tha latest packaged version for the system) I've visited setuptools' website (http://peak.telecommunity.com/DevCenter/setuptools) and it says in couple of places that the minimal requirement is python 2.3.5... I want to ask if any of you know it is safe to use setuptools with python-2.3.4? As far as I know 2.3.5 is "only" a bugfix release... I can't test it myself because the machine is a production server ;-) I will be very grateful for any help. Best regards, Maciej Zieba

3 3

[setuptools] running a post_install script
by Jon Peirce Aug. 24, 2006

Aug. 24, 2006

I've just been discovering the beauties of setuptools - for someone like me, developing a package with many dependencies, it could be just the tonic! And very easy to get going too - thnks! One question though - my package carries a post-install script to create a few shortcuts on windows systems. Creating an egg and then easy_installing it copies a setuptools version of the script to the scripts folder but it doesn't run at the end of install (or maybe it tries to and fails in some hidden way). The script does use the special functions from distutils [like get_special_folder_path(csidl_string)] and maybe these aren't available to setuptools? Am I missing something? Should it run? Or is it a simple limitation of eggs that they can't do this? The post-install script is attached below. thanks Jon http://www.psychopy.org/ #-------------------------------------- ##----------------------------- ##Windows post install (shortcuts etc...) ##----------------------------- import sys, os def install(): print "Adding shortcuts to >>Start>Programs>PsychoPy" progsFolder= get_special_folder_path("CSIDL_COMMON_PROGRAMS") sitePackages = os.path.join(sys.prefix , 'lib','site-packages') #Psychopy Programs folder psychopyShortcuts = os.path.join(progsFolder, 'PsychoPy') if not os.path.isdir(psychopyShortcuts): os.mkdir(psychopyShortcuts) directory_created(psychopyShortcuts) #monitor center monitorCenterLink=os.path.join(psychopyShortcuts, "MonitorCenter.lnk") if os.path.isfile(monitorCenterLink): os.remove(monitorCenterLink)#we want to make a new one create_shortcut(os.path.join(sitePackages,'monitors','MonitorCenter.py'), 'PsychoPy Monitor Center', monitorCenterLink) file_created(monitorCenterLink) #homepage homePageLink = os.path.join(psychopyShortcuts, "PsychoPyHome.lnk") if os.path.isfile(homePageLink): os.remove(homePageLink)#we want to make a new one create_shortcut(r"http://www.psychopy.org", 'PsychoPy HomePage', homePageLink) file_created(homePageLink) print "All done. Enjoy!" if len(sys.argv) > 1: if sys.argv[1] == '-install': install() else: print "Script was called with option %s" % sys.argv[1] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

2 1

dumb newbie...?
by Scott Finnie Aug. 23, 2006

Aug. 23, 2006

Please be gentle... Newbie to distutils, trying to install django 0.95 egg (www.djangoproject.com) from behind a corporate windows firewall. django in turn tries to download and install setuptools - which fails due to firewall. As per ez_setup.py error message, I downloaded the setuptools egg, put it in the same dir and re-ran: but got same message. Took a look at the code and found out why (expects the egg to be in the temp dir, not same dir). Strikes me it's most likely I was doing something wrong / missed an option / some other rudimentary mistake. Assuming that's the case, could someone set me straight? In the unlikely event I've found a bug I've attached a patched version below. Note the patch is anything but elegant, driven by minimal change rather than elegant solution. Very un-pythonic I know. Like I said, please be gentle... - Scoot. -- def download_setuptools( version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir, delay = 15 ): """Download setuptools from a specified location and return its filename `version` should be a valid setuptools version number that is available as an egg for download under the `download_base` URL (which should end with a '/'). `to_dir` is the directory where the egg will be downloaded. `delay` is the number of seconds to pause before an actual download attempt. """ import urllib2, shutil egg_name = "setuptools-%s-py%s.egg" % (version,sys.version[:3]) saveto = os.path.join(to_dir, egg_name) #------------------------------------------------ #Change begins #Don't download if the egg is in the current dir. #This is a horrible hack; should check for existence #in calling routine and possibly skip temp dir creation #altogether - depends on whether it's used subsequently by #setuptools. try: os.stat(egg_name) shutil.copyfile(egg_name, saveto) except: # change ends (remainder indented though) #------------------------------------------------ url = download_base + egg_name src = dst = None if not os.path.exists(saveto): # Avoid repeated downloads try: from distutils import log if delay: log.warn(""" --------------------------------------------------------------------------- This script requires setuptools version %s to run (even to display help). I will attempt to download it for you (from %s), but you may need to enable firewall access for this script first. I will start the download in %d seconds. (Note: if this machine does not have network access, please obtain the file %s and place it in this directory before rerunning this script.) ---------------------------------------------------------------------------""", version, download_base, delay, url ); from time import sleep; sleep(delay) log.warn("Downloading %s", url) src = urllib2.urlopen(url) # Read/write all in one block, so we don't create a corrupt file # if the download is interrupted. data = _validate_md5(egg_name, src.read()) dst = open(saveto,"wb"); dst.write(data) finally: if src: src.close() if dst: dst.close() return os.path.realpath(saveto)

2 3

Problems with cli.exe
by Jim Fulton Aug. 22, 2006

Aug. 22, 2006

I've found a bug with cli.exe and a missing feature. The bug is that arguments containing embedded spaces aren't handled correctly. For example, suppose you have foo-script.py and a copy of cli.exe named foo.exe. If you call foo.exe with a single argument, like this: foo "a b" then foo-script.py will be called with 2 arguments, "a", and "b", rather than a single argument, "a b". The missing feature is that options on the #! line aren't honored. It would be nice if, for example, a script beginning like: #!\Python24\python.exe -O would run Python in optimized mode. I'd be happy to take a crack at fixing the bug and adding the feature. Where is the source? I assume that this also applies to gui.exe. BTW, Shouldn't the setuptools project be moved out of sandbox and be made a proper svn project with it's own trunk, branches, and tags? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 4

Re: [Distutils] pkgfile entry points
by Phillip J. Eby Aug. 22, 2006

Aug. 22, 2006

At 08:57 AM 8/22/2006 +0100, James Casbon wrote: >Hi, > >I have an app which makes heavy use of rich ini style configuration files. >I would like to add the ability to extend it using pkg_resources entry >points. It seems quite natural here to use the entry point to refer to >the plugin configuration data like so: > >[myapp.extension] >something = pkgfile:extension/config.ini > >This single point would allow me to get the config data for the >plugin. Now, at the moment this style of entry point is not supported. I >could potentially get round this by asking all plugins to define an entry >point method that returns the location of the configuration file, but that >just creates another piece of tedious boilerplate to write. > >So, I'm wondering whether the inability to supply pkgfiles as entry points >is a deliberate design decision or just something that hadn't been anticipated? It wasn't anticipated, and yes, there have been other things that have come up since where it would've been useful (e.g. i18n). I considered making some changes to the format to allow some extensibility, but there isn't an easy way to maintain compatibility across setuptools versions with such changes. So, instead my thought is this: setuptools already allows any characters you want on the left side of the '=' sign, except for '='. So, you already have the ability to add arbitrary metadata to an entry point's name, e.g.: something (file:config.ini) = packagename As long as you do the parsing in your own code, this will work with any setuptools version. The string can be arbitrarily long, too, so you could define any number of 'prefix:value' variables. In general, I'm thinking that setuptools 0.7 will offer some kind of built-in (but optional) support for this kind of parsing and metadata, so that you can both specify it more easily in setup.py and handle it more easily in code.

1 0

pkgfile entry points
by James Casbon Aug. 22, 2006

Aug. 22, 2006

Hi, I have an app which makes heavy use of rich ini style configuration files. I would like to add the ability to extend it using pkg_resources entry points. It seems quite natural here to use the entry point to refer to the plugin configuration data like so: [myapp.extension] something = pkgfile:extension/config.ini This single point would allow me to get the config data for the plugin. Now, at the moment this style of entry point is not supported. I could potentially get round this by asking all plugins to define an entry point method that returns the location of the configuration file, but that just creates another piece of tedious boilerplate to write. So, I'm wondering whether the inability to supply pkgfiles as entry points is a deliberate design decision or just something that hadn't been anticipated? You might suggest that the configuration should be done as entry points. However, the ini file structure used is more rich than supported by entry points and to use them would require moving lots of configuration data into python code. I do therefore think that this is a legitimate use. thanks, James

1 0

"zip_safe flag not set; analyzing archive contents..." should be info, not a warning
by Jim Fulton Aug. 16, 2006

Aug. 16, 2006

IMO, the message "zip_safe flag not set; analyzing archive contents..." should be an info message, not a warning message, at lease when processing non-setuptools-based source distribution. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

pkg_resources.declare_namespace vs pkgutil.extend_path
by Jim Fulton Aug. 11, 2006

Aug. 11, 2006

We currently have two ways of implementing namespace packages, pkg_resources.declare_namespace vs pkgutil.extend_path Do we need 2? What does pkg_resources.declare_namespace do that pkgutil.extend_path does, other than provide zip file support? Can we consolidate them somehow? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1