Mailman 3 June 2005 - Distutils-SIG

Re: [Distutils] distutils install probs on suse 9.0
by Mats Wichmann April 29, 2018

April 29, 2018

At 05:43 AM 5/18/2004, David Handy wrote: >On Tue, 18 May 2004, Floris van der Tak wrote: > >> my attempt to install the distutils on suse 9.0 (which provides python >> 2.3) fails: > >Why are you installing distutils on a system that already has Python 2.3 >installed? Python 2.3 normally comes with distutils as part of the Python >standard library. > >Did suse distribute a version of Python that had distutils removed? It should come from python-devel

2 1

Sample setup.py for Numeric Python
by Greg Ward April 29, 2018

April 29, 2018

Hi again -- [cc'd to Paul Dubois: you said you weren't following the distutils sig anymore, but this directly concerns NumPy and I'd like to get your input!] here's that sample setup.py for NumPy. See below for discussion (and questions!). ------------------------------------------------------------------------ #!/usr/bin/env python # Setup script example for building the Numeric extension to Python. # This does sucessfully compile all the .dlls. Nothing happens # with the .py files currently. # Move this file to the Numerical directory of the LLNL numpy # distribution and run as: # python numpysetup.py --verbose build_ext # # created 1999/08 Perry Stoll __rcsid__ = "$Id: numpysetup.py,v 1.1 1999/09/12 20:42:48 gward Exp $" from distutils.core import setup setup (name = "numerical", version = "0.01", description = "Numerical Extension to Python", url = "http://www.python.org/sigs/matrix-sig/", ext_modules = [ ( '_numpy', { 'sources' : [ 'Src/_numpymodule.c', 'Src/arrayobject.c', 'Src/ufuncobject.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/numpy.def' } ), ( 'multiarray', { 'sources' : ['Src/multiarraymodule.c'], 'include_dirs' : ['./Include'], 'def_file': 'Src/multiarray.def' } ), ( 'umath', { 'sources': ['Src/umathmodule.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/umath.def' } ), ( 'fftpack', { 'sources': ['Src/fftpackmodule.c', 'Src/fftpack.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/fftpack.def' } ), ( 'lapack_lite', { 'sources' : [ 'Src/lapack_litemodule.c', 'Src/dlapack_lite.c', 'Src/zlapack_lite.c', 'Src/blas_lite.c', 'Src/f2c_lite.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/lapack_lite.def' } ), ( 'ranlib', { 'sources': ['Src/ranlibmodule.c', 'Src/ranlib.c', 'Src/com.c', 'Src/linpack.c', ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/ranlib.def' } ), ] ) ------------------------------------------------------------------------ First, what d'you think? Too clunky and verbose? Too much information for each extension? I kind of think so, but I'm not sure how to reduce it elegantly. Right now, the internal data structures needed to compile a module are pretty obviously exposed: is this a good thing? Or should there be some more compact form for setup.py that will be expanded later into the full glory we see above? I've already made one small step towards reducing the amount of cruft by factoring 'include_dirs' out and supplying it directly as a parameter to 'setup()'. (But that needs code not in the CVS archive yet, so I've left the sample setup.py the same for now.) The next thing I'd like to do is get that damn "def_file" out of there. To support it in MSVCCompiler, there's already an ugly hack that unnecessarily affects both the UnixCCompiler and CCompiler classes, and I want to get rid of that. (I refer to passing the 'build_info' dictionary into the compiler classes, if you're familiar with the code -- that dictionary is part of the Distutils extension-building system, and should not propagate into the more general compiler classes.) But I don't want to give these weird "def file" things standing on the order of source files, object files, libraries, etc., because they seem to me to be a bizarre artifact of one particular compiler, rather than something present in a wide range of C/C++ compilers. Based on the NumPy model, it seems like there's a not-too-kludgy way to handle this problem. Namely: if building extension "foo": if file "foo.def" found in same directory as "foo.c" add "/def:foo.def" to MSVC command line this will of course require some platform-specific code in the build_ext command class, but I figured that was coming eventually, so why put it off? ;-) To make this hack work with NumPy, one change would be necessary: rename Src/numpy.def to Src/_numpy.def to match Src/_numpy.c, which implements the _numpy module. Would this be too much to ask of NumPy? (Paul?) What about other module distributions that support MSVC++ and thus ship with "def" files? Could they be made to accomodate this scheme? Thanks for your feedback -- Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

4 5

Can now compile simple extensions
by Greg Ward April 29, 2018

April 29, 2018

Hi all -- at long last, I found the time to hack in the ability to compile extension modules to the Distutils. Mainly, this meant adding a 'build_ext' command which uses a CCompiler instance for all its dirty work. I also had to add a few methods to CCompiler (and, of course, UnixCCompiler) to make this work. And I added a new module, 'spawn', which takes care of running sub-programs more efficiently and robustly (no shell involved) than os.system. That's needed, obviously, so we can run the compiler! If you're in the mood for grubbing over raw source code, then get the latest from CVS or download a current snapshot. See http://www.python.org/sigs/distutils-sig/implementation.html for a link to the code snapshot. I'm still waiting for more subclasses of CCompiler to appear. At the very least, we're going to need MSVCCompiler to build extensions on Windows. Any takers? Also, someone who knows the Mac, and how to run compilers programmatically there, will have to figure out how to write a Mac-specific concrete CCompiler subclass. The spawn module also needs a bit of work to be portable. I suspect that _win32_spawn() (the intended analog to my _posix_spawn()) will be easy to implement, if it even needs to go in a separate function at all. It looks from the Python Library documentation for 1.5.2 that the os.spawnv() function is all we need, but it's a bit hard to figure out just what's needed. Windows wizards, please take a look at the 'spawn()' function and see if you can make it work on Windows. As for actually compiling extensions: well, if you can figure out the build_ext command, go ahead and give it a whirl. It's a bit cryptic right now, since there's no documentation and no example setup.py. (I have a working example at home, but it's not available online.) If you feel up to it, though, see if you can read the code and figure out what's going on. I'm just hoping *I'll* be able to figure out what's going on when I get back from the O'Reilly conference next week... ;-) Enjoy -- Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Two fixes (at last)
by Greg Ward April 29, 2018

April 29, 2018

Hi all -- at long last, I have fixed two problems that a couple people noticed a while ago: * I folded in Amos Latteier's NT patches almost verbatim -- just changed an `os.path.sep == "/"' to `os.name == "posix"' and added some comments bitching about the inadequacy of the current library installation model (I think this is Python's fault, but for now Distutils is slavishly aping the situation in Python 1.5.x) * I fixed the problem whereby running "setup.py install" without doing anything else caused a crash (because 'build' hadn't yet been run). Now, the 'install' command automatically runs 'build' before doing anything; to make this bearable, I added a 'have_run' dictionary to the Distribution class to keep track of which commands have been run. So now not only are command classes singletons, but their 'run' method can only be invoked once -- both restrictions enforced by Distribution. The code is checked into CVS, or you can download a snapshot at http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz Hope someone (Amos?) can try the new version under NT. Any takers for Mac OS? BTW, all parties involved in the Great "Where Do We Install Stuff?" Debate should take a good, hard look at the 'set_final_options()' method of the Install class in distutils/install.py; this is where all the policy decisions about where to install files are made. Currently it apes the Python 1.5 situation as closely as I could figure it out. Obviously, this is subject to change -- I just don't know to *what* it will change! Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

2 1

Package versioning
by Timothy Docker April 29, 2018

April 29, 2018

Hi all, I've been aware that the distutils sig has been simmerring away, but until recently it has not been directly relevant to what I do. I like the look of the proposed api, but have one question. Will this support an installed system that has multiple versions of the same package installed simultaneously? If not, then this would seem to be a significant limitation, especially when dependencies between packages are considered. Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks. A package is installed with its version number in it's name, and a separate directory is created for an application with links from the unversioned package name to the versioned one. Then I just set the pythonpath to this directory. A sample of what the directory looks like is shown below. I'm sure there is a better solution that this, and I'm not sure that this would work under windows anyway (does windows have symlinks?). So, has this SIG considered such versioning issues yet? Cheers, Tim -------------------------------------------------------------- Tim Docker timd(a)macquarie.com.au Quantative Applications Division Macquarie Bank -------------------------------------------------------------- qad16:qad $ ls -l lib/python/ total 110 drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1 -r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1 dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8 drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1 dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1 dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7 dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1 qad16:qad $ ls -l lib/python/1.1 total 30 lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1 lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8 lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1 lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1 lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3 lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7 lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1

3 2

[Distutils-sig] distutils charter and interscript
by John Skaller April 29, 2018

April 29, 2018

3 2

EasyInstall 0.4a1: now with PyPI autodownload
by Phillip J. Eby Aug. 1, 2005

Aug. 1, 2005

I've just released a new version of EasyInstall, that supports automatic package location via PyPI; installing a package can now be as simple as: easy_install "SQLObject>=0.6" There are many new options and features related to this; see the EasyInstall home page for more information: http://peak.telecommunity.com/DevCenter/EasyInstall For the benefit of the PyPI maintainers, here is a summary of EasyInstall's fairly minimal assumptions about PyPI's current behavior, assuming that "base-url" is the root URL of the package index: * Going to "base-url/SomePackage" produces an HTML page that either has a title containing "Index of Packages" and links to zero or more pages for specific versions, or else it is a single-version package page. * Single-version package pages may have a home page and download URL link, each of which occurs after '<th>Home Page' and '<th>Download URL' respectively, if present. * Going to "base-url/" (note trailing '/') produces an HTML page containing links to all active versions of registered packages * Links to package pages always have URLs of the form "base-url/SomePackage/itsVersion" - i.e., exactly two path parts following the base URL, with no query strings, parameters, fragments, etc. EasyInstall should continue to work with PyPI if these assumptions continue to hold. However, I'd also like to suggest that PyPI deprecate the use of spaces and other non-alphanumeric characters (other than '-') in package names, and move to a case-insensitive matching mechanism for package names. (Currently, if a user types a package name in the wrong case, EasyInstall downloads the full package list in order to do its own case-insensitive search.) By the way, EasyInstall does not rely solely on the download URL of a PyPI entry, nor does it assume that the download URL is in fact the URL where the package's source distribution is found. Instead, EasyInstall inspects the URLs for whether the extension suggests an egg or source distribution. If not, it retrieves the listed URL, and if it contains HTML, it scans the HTML for links to egg or source distributions (again identified by extension). It does this for both the home page and the download URL, in case there is a usable download link on the package's home page. This approach was chosen to maximise the odds of successful downloading, given the current contents of PyPI.

1 1

PyPI upload doesn't support eggs?
by Phillip J. Eby June 30, 2005

June 30, 2005

I can't seem to convince the "upload" command to send egg distributions to PyPI. I'm using the CVS head version of "upload", and modified bdist_egg to add the necessary information to distribution.dist_files, but attempting to upload gives this response (using --show-response): Submitting dist\setuptools-0.5a4-py2.3.egg to http://www.python.org/pypi Upload failed (500): There's been a problem with your request --------------------------------------------------------------------------- Erro r... There's been a problem with your request exceptions.ValueError: invalid distribution file ------------------------------- -------------------------------------------- Any suggestions?

6 12

--build-base and install
by Barry Warsaw June 30, 2005

June 30, 2005

I'm trying to build and install pysqlite-1.1.6 using --build-base, because I want the files created during the build to be placed in a specific directory outside the source directory. --build-base works just fine with the 'build' command, but not at all with the 'install' command. How is 'install' supposed to find the files that 'build' placed elsewhere? Is the lack of --build-base support a problem with pysqlite's setup.py script or a more fundamental problem with distutils? Or am I just being dense? FTR: Python 2.4.1 Thanks, -Barry

5 5

Question about checking version
by Pranav Bagora June 30, 2005

June 30, 2005

Hello, i am a newbie using distutils... i m trying to make a installer for windows which will compile few python files. What i want to know is that if i am creating a newer version of the installer how do i check for the previous versions installed and also install newer versions in a separate directory. Thanks Pranav Bagora Graduate Student SUNY Binghamton. ================ Add:- 261 Main Street Apt No. 11 Binghamton NY. ================ Phone:- 607 349 8788 email:- pbagora(a)binghamton.edu ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com

1 0

Can distutils manage static libraries and fortran compilers ?
by mathieu gontier June 30, 2005

June 30, 2005

Hello I work on an finite element framework and Python bindings have been developped. Actually, we use Boost.Build as build system but we would like to change it. We have two kinds of problems. First, the framework is used for generate pure C++ applications with static libraries ; second, the framework have some dependencies to fortran projects. Then, in order to know if Distutils can be use in our case, I would like to know if : - Can distutil compile static C/C++ libraries ? - Can distutil compile C/C++ applications ? - Can distutil manage fortran compiler and compile fortran libraries and applications ? Thank for your answers,

2 1

Installing dependencies
by Phillip J. Eby June 25, 2005

June 25, 2005

I don't quite know yet how EasyInstall should handle dependencies. I do know that I want it to use the metadata from a built egg to determine those dependencies, and that it should also include dependencies for any "extras" (see my last terminology post) that were requested on the EasyInstall command line. I also know that these dependencies can't really be handled by pretending they were included on the original command line, because that implies e.g. copying the package to the installation directory, and possibly munging .pth files. For example, if you already have one of the dependencies installed in --multi-version mode, but are installing a new package in single-version, you don't necessarily want to switch the existing package to single-version, do you? Then again, maybe you do. After all, if you're installing in single-version, you probably want stuff to "just work", and resetting the current version of the dependency would be the right thing in that case. EasyInstall should probably just be louder about the fact that it's changing the currently-active version. Maybe a post-installation report about what versions of relevant packages are active (w/"before and after" version information) would address this issue. Okay, what about the reverse scenario? You're installing --multi-version, but one of the dependencies is already single-version? That really needs to be left alone. And what if there's a conflicting requirement with an existing single-version install? Changing the active version might break something else, so we'd need to spit out a warning, explaining how to fix it (by changing the active version of the dependencies). Finally, EasyInstall currently always ensures there is a copy of the desired distribution in the installation directory. So, if you are installing somewhere other than site-packages, but your dependencies can be met using distributions in site-packages, should we still copy the distributions? I think it's always a safe default to do the copying, because disk space is cheap, and it makes the installation more independent of the Python installation and environment used to create it. However, I can also see that sometimes you might want to avoid this, but I'm not really sure what the option should be called. --no-copy, perhaps? (meaning, don't copy distributions found on sys.path to the --install-dir.) On a related note, it seems to me that setuptools can and maybe should change its 'install' command to actually use EasyInstall, such that running 'setup.py install' for a package using setuptools, does the same thing as it would have if you'd used EasyInstall to install it. This might force some people to use 'require()' who otherwise would not have, but I'm not sure how much of a problem that is in practice. Really, if Python 2.5 ends up supporting .pth files in any sys.path directory, the problem will go away because EasyInstall could avoid forcing --multi-version when a custom installation directory is used. Anyway, aside from the easy package management and other features of using easy_install as the 'install' command, it would also enable the traditional 'setup.py install' to include the distributed package's dependencies as well. This means that we could finally make it easy for people to distribute packages with external dependencies, because the only thing they'll have to include is the 'ez_setup.py' bootstrap script alongside their setup.py. The principal problem I see with this is that some distutils commands internally access the 'install' command in order to get information or to perform a pseudo-installation for creating binary distributions. So, there might be some interesting technical hurdles in order to make it such that running 'install' from the command line does one thing, but 'install' called internally from a 'bdist' command does something else. I'll have to investigate that a bit. It would also be nice if you could specify your dependencies as part of the 'setup()' script, but it looks like some people are trying to use the 'requires' keyword for PEP 314's non-semantic metadata. Personally I think PEP 314 is going in the wrong direction at the moment, because it doesn't specify any semantics for the metadata. Having more fields for people to fill out with data we can't use isn't very helpful. And, at the same time, the PEP 314 spec is too strict about how versions are defined, and doesn't support "extra" (optional) requirements. I should probably make a concrete proposal for revising PEP 314 to: 1. Define semantics for "Requires" strings (PyPI project names) 2. Suggest removing "Provides", in favor of distributing only a single "provided" thing per distribution at the present time. 3. Suggest renaming "Obsoletes" to "Conflicts" 4. Define a package version syntax based on setuptools' rules 5. Allow Download-URL to be a link to an HTML page containing direct links to downloadable distributions, so that PyPI and Sourceforge download pages are acceptable (note that PEP 314 doesn't currently let you publish links to binary distributions, only source). What I'd like to do with setuptools is allow you to use keywords like the following, in order to define your distribution's required dependencies and any optional extra features that incur additional dependencies: setup( ... requires = ["SomePackage>=1.2", "OtherPackage"], extras = dict( reST = ["docutils>=0.3.5", "restEdit>=0.3"], XML = ["xmlplus"], ... ) ... ) But that won't work too well if the 'requires' conflicts with what PEP 314 is after, and the current Python CVS trunk implements.

1 0

Terminology for distributions, eggs, setuptools, etc.
by Phillip J. Eby June 25, 2005

June 25, 2005

I'm trying to define some meaningful terms for talking about eggs and what they contain, as I prepare for some refactoring to make the egg runtime's class and attribute names be more consistent. Currently, the terminology driving those names has been kind of vague and handwavy; I'd like to get a little more precise. So, the following is an attempt at working out a coherent vocabulary, conceptual framework, and architectural overview of "Pluggable Distributions" (i.e., eggs). My plan is to refactor pkg_resources, setuptools.packge_index, and possibly some other parts of setuptools to match the more formal concept hierarchy laid out here. I'd appreciate any feedback, but it needs to be fairly soon as there should ideally be only one "great renaming", marking the transition of setuptools from 0.5 to 0.6, with a stable API for extenders going forward. Pluggable Distributions of Python Software ========================================== A "Distribution" is a collection of files that represent a "Release" of a "Project" as of a particular point in time, denoted by a "Version". Releases may have zero or more "Requirements", which indicate what releases of another project the release requires in order to function. A Requirement names the other project, expresses some criteria as to what releases of that project are acceptable, and lists any "Extras" that the requiring release may need from that project. (An Extra is an optional feature of a Release, that can only be used if its additional Requirements are satisfied.) Notice, by the way, that this definition of Distribution is broad enough to include directories containing Python packages or modules, not just "built distributions" created by the distutils. For example, the directory containing the Python standard library is a "distribution" by this definition, and so are the directories you edit your project's code in! In other words, every copy of a project's code is a "distribution", even if you don't take any special steps to make it one. Not all distributions are "importable", however. An "importable" distribution is one whose file or directory name can be referenced on sys.path, to allow importing modules or packages from that distribution. So, simple directories of code (and zipfiles with the correct internal layout) are "importable distributions", but most of the distributions built by the distutils (source archives and binary installers) are not. A "Project" is a library, framework, script, application, or collection of data or other files relevant to Python. "Projects" must have unique names, in order to tell them apart. Currently, PyPI is useful as a way of registering project names for uniqueness, because the 'name' argument to distutils 'setup()' command is used to identify the project on PyPI, as well as to generate Distributions' file names. A "Pluggable Distribution" or "Pluggable", is an importable distribution that satisfies these important additional properties: 1. Its project name and distribution format can be unambiguously determined from file or directory names, without actually examining any file contents. (Most distutils distribution formats cannot guarantee this, because they do not place any restrictions on project name strings, and thus allow ambiguity as to what part of their filenames is the project name, and what part is the version.) 2. A pluggable distribution contains metadata identifying its release's version, requirements, extras, and any additional requirements needed to implement those extras. It may also contain other metadata specific to an application or framework, to support integrating the pluggable's project with that application or framework. Distributions that satisfy these two properties are thus "pluggable", because they can be automatically discovered and "activated" (by adding them to sys.path), then used for importing Python modules or accessing other resource files and directories that are part of the distributed project. The Working Set --------------- The collection of distributions that are currently activated is called a Working Set. Note that a Working Set can contain any importable distribution, not just pluggable ones. For example, the Python standard library is an importable distribution that will usually be part of the Working Set, even though it is not pluggable. Similarly, when you are doing development work on a project, the files you are editing are also a Distribution. (And, with a little attention to the directory names used, and including some additional metadata, such a "development distribution" can be made pluggable as well.) When Python runs a program, that program must have all its requirements met by importable distributions in the working set. Initially, a Python program's Working Set consists only of the importable distributions (whether pluggable or not) listed in sys.path, such as the directory containing the program's __main__ script, and the directories containing the standard library and site-packages. If these are the only distributions that the program requires, then of course that program can run. However, if some of the requirements are not satisfied by the working set, this can lead to errors that may be hard to diagnose. So, if a Python program were made part of a Project, and the project explicitly defines its Requirements, which are then expressed as part of a Pluggable Distribution, then a runtime facility could automatically attempt to locate suitable pluggables and add them to the working set, or at least give a more specific error message if a requirement can't be satisfied. The Environment --------------- A set of directories that may be searched for pluggable distributions is called an Environment. By default, the Environment consists of all existing directories on sys.path, plus any distribution sources registered with the runtime. Given an Environment, and a Requirement to be satisfied, our proposed runtime facility would search the environment for pluggable distributions that satisfy the requirement (and the requirements of those distributions, recursively), such that it returns a list of distributions to be added to the working set, or raises a DependencyNotFound error. Note that a Working Set should not contain multiple distributions for the same project, so the runtime system must not propose to add a pluggable distribution to a Working Set if that set already contains a pluggable for the same project. If a project's requirements can't be met without adding a conflicting pluggable to the working set, a VersionConflict error is raised. (Unlike a working set, an Environment may contain more than one pluggable for a given project, because these are simply distributions that are *available* to be activated.) Python Eggs ----------- "Python Eggs" are distributions in specific formats that implement the concept of a "Pluggable Distribution". An egg may be a zipfile or directory whose name ends with '.egg', that contains Python modules or packages, plus an 'EGG-INFO' subdirectory containing metadata. An egg may also be a directory containing one or more 'ProjectName.egg-info' subdirectories with metadata. The latter form is primarily intended to add discoverability to distributions that -- for whatever reason -- cannot be restructured to the primary egg format. For example, by placing appropriate .egg-info directories in site-packages, one could document what distributions are already installed in that directory. While this would not make those releases capable of being individually activated, it does allow the runtime system to be aware that any requirements for those projects are already met, and to know that it should not attempt to add any other releases of those projects to the working set. The last form of egg is a '.egg-link' file. These exist to support symbolic linking on platforms that do not natively support symbolic links (e.g. Windows). These consist simply of a single line indicating the location of a directory that contains either an EGG-INFO or ProjectName.egg-info subdirectory. This format will be used by project management utilities to add an in-development distribution to the development Environment. Initialization, Development, and Deployment ------------------------------------------- Pluggable distributions can be manually made part of the working set by modifying sys.path. This can be done via PYTHONPATH, .pth files, or direct code manipulation. However, it is generally more useful to put distributions in the working set by automatically locating them in an appropriate Environment. The default Environment is the directories already on sys.path, so simply placing pluggable distributions in those directories suffices to make them available for adding to the working set. But *something* must add them to the working set, even if it is just to designate the project the current program is part of, so that its dependencies can be automatically resolved and added to the working set. This means that either a program's start scripts must invoke the runtime facility and make this initial request, or there must be some automatic means by which this is accomplished. The EasyInstall program accomplishes this by creating wrapper scripts when a distribution is installed. The wrapper scripts know what project the "real" script is part of, and so can ensure that the right working set is active when the scripts run. The scripts' author does not need to invoke the runtime facility directly, nor do they even need to be aware that it exists. For development, however, one does not generally want to have to "install" scripts that one is actively editing. So, future versions of the runtime facility will have an option to automatically create wrapper scripts that invoke the in-development versions of the scripts, rather than versions installed in eggs. This will allow developers to continue to write scripts without embedding any project or version information in them. Essentially, for development purposes, there will be a tool to "install" an in-development distribution to a given Environment, using a symlink or .egg-link file to include the distribution, and generating wrapper scripts to invoke any "main program" scripts in the project. Thus, a user's development Environment can include one or more projects whose source code he or she is editing, as well as any number of built distributions. He or she can then also build source or binary distributions of their project for deployment, whenever it is necessary or convenient to do so.

1 0

EasyInstall: scripts aren't executable?
by Ryan Tomayko June 23, 2005

June 23, 2005

So EasyInstall wrapper scripts don't get any executable bits set when installed. Was this an intentional omission or just oversight? Note that you won't see the problem if the script already exists with +x when it is installed. diff -u -r1.22 easy_install.py --- easy_install.py 15 Jun 2005 02:23:47 -0000 1.22 +++ easy_install.py 23 Jun 2005 17:32:20 -0000 @@ -238,7 +238,8 @@ f = open(target,"w") f.write(script_text) f.close() - + from os import chmod + chmod(target, 0755) Ryan Tomayko rtomayko(a)gmail.com http://naeblis.cx/rtomayko/

2 1

Moving distutils minimum required version to 2.3
by Anthony Baxter June 22, 2005

June 22, 2005

I've checked distutils into the python sandbox for a major chunk of refactoring, including killing distutils.log and distutils.fancy_getopt. I plan to upgrade the minimum required version of distutils to 2.3 - I will be using the logging and optparse modules from the stdlib. This means that the version of distutils included in 2.4 will be the last version guaranteed to work on 2.1 and 2.2 -- but I seriously question whether anyone is ever going to be making standalone distutils distributions again. If you know of any problems with this, please let me know. Thanks, Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

3 4

Re: [Distutils] Absolute destination path in data_files
by Phillip J. Eby June 21, 2005

June 21, 2005

At 01:39 PM 6/21/2005 -0500, Taylor, Martin wrote: >You're probably right about using "scripts=", but I can't figure out its >syntax, either (the manual is VERY LIGHT on useful examples). If I >listed some scripts, I'd want to put them in a more package-specific >place than C:\Python24\Scripts. But I can't figure out if that's >possible. You can create and distribute a setup.cfg file with your package, containing something like: [install] install_scripts = /FOO/Scripts/Whatever And users can override it with --install-scripts or by editing setup.cfg This will have no effect on the bdist_wininst installer (or other wrappers like EasyInstall, bdist_rpm, etc.), only on packages installed using setup.py

1 0

Absolute destination path in data_files
by Taylor, Martin June 21, 2005

June 21, 2005

In the document "Distributing Python Modules" by Greg Ward, section "2.6 Installing Additional Files" has the following example: setup(... data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']), ('config', ['cfg/data.cfg']), ('/etc/init.d', ['init-script'])] ) which I understand to be showing, in the last line, that a path proceeded by a "/" is an absolute destination path for the file names following it. When I try this in the following example: setup(name="FOO", description="FOO - A Generic Package", version=__version__, package_dir = {"FOO" : "Core", "FOO.EngA" : "EngA", "FOO.EngB" : "EngB"}, packages = ["FOO", "FOO.EngA", "FOO.EngB"], data_files=[('/FOO/FOO_BAR', ["UtilA\CMDTestClient.py", "UtilA\StopTestServer.py", "UtilA\TestClient.py", "UtilA\TestServer.py"] )], author="C. Martin Taylor", author_email="cmtaylor(a)ti.com <mailto:cmtaylor@ti.com> " ) and then build it with the command: python setup.py bdist --format=wininst I get the following error messages: C:\FOO>python setup.py bdist --format=wininst running bdist running bdist_wininst running build running build_py installing to build\bdist.win32\wininst running install_lib creating build\bdist.win32\wininst creating build\bdist.win32\wininst\PURELIB creating build\bdist.win32\wininst\PURELIB\FOO creating build\bdist.win32\wininst\PURELIB\FOO\EngA copying build\lib\FOO\EngA\EngA.py -> build\bdist.win32\wininst\PURELIB\FOO\EngA copying build\lib\FOO\EngA\__init__.py -> build\bdist.win32\wininst\PURELIB\FOO\EngA creating build\bdist.win32\wininst\PURELIB\FOO\EngB copying build\lib\FOO\EngB\EngB.py -> build\bdist.win32\wininst\PURELIB\FOO\EngB copying build\lib\FOO\EngB\EngBConstants.py -> build\bdist.win32\wininst\PURELIB\FOO\EngB copying build\lib\FOO\EngB\__init__.py -> build\bdist.win32\wininst\PURELIB\FOO\EngB copying build\lib\FOO\FOO.py -> build\bdist.win32\wininst\PURELIB\FOO copying build\lib\FOO\FOOLog.py -> build\bdist.win32\wininst\PURELIB\FOO copying build\lib\FOO\FOO_CommonCode.py -> build\bdist.win32\wininst\PURELIB\FOO copying build\lib\FOO\FOO_UDF.py -> build\bdist.win32\wininst\PURELIB\FOO copying build\lib\FOO\FOO_Version.py -> build\bdist.win32\wininst\PURELIB\FOO copying build\lib\FOO\__init__.py -> build\bdist.win32\wininst\PURELIB\FOO running install_data creating build\bdist.win32\wininst\DATA Traceback (most recent call last): File "setup.py", line 49, in ? author_email="cmtaylor(a)ti.com <mailto:cmtaylor@ti.com> " File "C:\Python24\lib\distutils\core.py", line 149, in setup dist.run_commands() File "C:\Python24\lib\distutils\dist.py", line 946, in run_commands self.run_command(cmd) File "C:\Python24\lib\distutils\dist.py", line 966, in run_command cmd_obj.run() File "C:\Python24\lib\distutils\command\bdist.py", line 146, in run self.run_command(cmd_name) File "C:\Python24\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "C:\Python24\lib\distutils\dist.py", line 966, in run_command cmd_obj.run() File "C:\Python24\lib\distutils\command\bdist_wininst.py", line 152, in run install.run() File "C:\Python24\lib\distutils\command\install.py", line 505, in run self.run_command(cmd_name) File "C:\Python24\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "C:\Python24\lib\distutils\dist.py", line 966, in run_command cmd_obj.run() File "C:\Python24\lib\distutils\command\install_data.py", line 62, in run dir = convert_path(f[0]) File "C:\Python24\lib\distutils\util.py", line 89, in convert_path raise ValueError, "path '%s' cannot be absolute" % pathname ValueError: path '/FOO/FOO_BAR' cannot be absolute Does anyone have an idea what is wrong here? Am I misinterpreting the document, or is there a bug in ActivePython 2.4? Thank you, C. Martin Taylor Sr. Test Automation Specialist Texas Instruments, Inc. Educational and Productivity Solutions

2 1

EasyInstall: Issue: wrapper script weirdness
by Ryan Tomayko June 20, 2005

June 20, 2005

I was able to package py.test (and the rest of py.lib) into an egg without much issue. I ran into a small problem with the py.test script, however, and the issue could effect other scripts as well. There is a main script, "py.test", that is very short:: from _Findlay import py py.test.cmdline.main() py.lib is packaged such that "_findpy.py" is installed as a script so it sits next to py.test under PKG-INFO/scripts and a wrapper is generated at [script-dir]/_findpy.py as well. _findpy just does some sys.path munging on import and then brings in the py module. For clarity, we have a set of files that look like this (on my machine): /usr/local/bin/py.test (setuptools wrapper) /usr/local/bin/_findpy.py (setuptools wrapper) py.test.egg/PKG-INFO/scripts/py.test (actual script) py.test.egg/PKG-INFO/scripts/_findpy.py (actual module) When I try to run the script using the setuptools generated wrapper I get:: ImportError: cannot import name py <bonus points if you figured it out already> This is happening on the "from _findpy import py" line in PKG-INFO/ scripts/py.test. The text of ImportError looked more like a circular import problem than a "module not found" problem so I checked it out and the PKG-INFO/scripts/_findpy module is indeed being loaded and executed and it is finding the "py" package okay. What's happening is that '/usr/local/bin' comes before 'PKG-INFO/ scripts' on sys.path so that execution moves something like this: 1. `/usr/local/bin/py.test` 2. execfile `PKG-INFO/scripts/py.test` 3. import _findpy (found at `/usr/local/bin/_findpy.py`) 4. execfile `PKG-INFO/scripts/_findpy.py` Step three is bad. It would probably be best to make py.lib's scripts a little less complex (installing _findpy.py as a script doesn't strike me as an elegant approach). On the other hand, the way setuptools lays out sys.path when wrapper scripts are invoked results in unexpected behavior. If a script is importing a module it believes to be in the same directory, it is definitely not wanting to import the wrapper version. It may be best to remove the wrapper script directory from sys.path entirely or at least push it back behind the PKG-INFO/ scripts directory. I can't think of a single scenario where a wrapped script would want to import another wrapper. I haven't tried anything yet but will fire off a patch if I get in there to have a look. Ryan Tomayko rtomayko(a)gmail.com http://naeblis.cx/rtomayko/

2 2

cracked eggs
by Ryan Tomayko June 20, 2005

June 20, 2005

I've noticed that many packages that use __file__ and path operations instead of the pkg_resources / PEP 302 APIs to load package data usually work fine if you move the .egg file out of the way and then extract it to a directory with the same name. I have a little shell script ("crack_egg") that does this for me but I was wondering if this might be something that package authors could specify for their packages somehow, or maybe easy_install could take a command line arg or something? I guess it gets pretty messy. I remember reading somewhere that .egg files speed up import times over .egg directories because the zip index is quicker than the file system or something. But is it really that significant? Considering that a decent number of potential eggs are broken due to the resource API I wonder if it might be nice to have the option to prefer .egg directories for all packages installed by easy_install (e.g. by defaulting some option in ~/pydistutils.cfg). here's that script: $ cat $(which crack_egg) #!/bin/bash # usage: crack_egg egg-file [egg-file] ... for arg in $@ ; do mv $arg{,.zip} mkdir $arg unzip -d $arg $arg.zip done Ryan Tomayko rtomayko(a)gmail.com http://naeblis.cx/rtomayko/

2 2

Re: [Distutils] EasyInstall: Issue: installing versioned modules by default, specifying version at runtime, lazy load highest by default.
by Phillip J. Eby June 17, 2005

June 17, 2005

At 01:35 PM 6/17/2005 +0100, Clayton Brown wrote: >Sometime ago, well at least before this modern marvel of eggs/easy >install etc, I wrote / adapted a bootstrap loader to enable module >versioning / specification at time of import, its default behaviour >was to load the highest version at the level of specification eg. > >_foo_version__ == "1.2.3" will load 1.2.3.99 etc where one exists >but no specification will import 99.99.99.99 etc. > >ref: http://claytonbrown.com/cbwiki/ModuleVersioning / >http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/285215 > >could the easy_install / import mechanism accomodate such installation >/ import hooks, (perhaps by just importing a module to invoke this >behaviour) so that by default eggs are all installed and versioned, >and if no version is specified by using require the highest version is >loaded, and when require() is used unless exact version is specified >it will import higher versions at the depth of specification should >they become available. Though by the looks of pkg_resources.require() >this may just be for system binary dependancies, not modules. > >my idea is that it would be nice to use -m on every installed package >to get versioned modules in site-packages, but not force require() >within scripts,just default to importing highest released version if >require() doesn't specifify a differnet version. When EasyInstall installs a script, it actually installs a stub that effectively require()s the coresponding egg, then runs the original script. So, you don't actually have to use require() at all, if you use EasyInstall to install some existing project's distribution. The exact version that supplied the scripts will be require()d for you automatically. require() is really only intended to bootstrap activation of the script's distribution; it isn't intended to be used throughout an application anyway. One very important reason why not, is that require() embedded in modules is not discoverable. There is no way to automatically find out what versions of things a package requires, and thereby automatically install those versions, if it is buried in code. This is why eggs have a depends.txt file where all the dependencies are centrally listed, allowing automated tools to deal with them. These dependencies are based on project names, not on individual modules or packages, because project names are discoverable (e.g. via PyPI) and package names are potentially far more numerous. So, although your approach has lots of merit, it doesn't accomplish the larger goal for Eggs, which is to support upgradeable applications and application servers, and to make it easy to add/remove Python packages from an application or Python installation. Versioned importing is just the tip of the iceberg for eggs, something that almost falls out as a side effect, rather than being a direct goal. Really, eggs more have the goal of *eliminating the need* for versioned importing, rather than implementing it! :)

1 0

EasyInstall: development environment
by Ian Bicking June 16, 2005

June 16, 2005

Working from Phillip's last email, here's my proposed list of steps for creating a development environment; some of these could be automated, but lets presume the automation does the same thing this manual process does... Application name: MyApp # We don't care where this directory is, except that we put all our # in-development checkouts here... cd ~/devel-directory mkdir MyApp # or an svn repository /MyApp/trunk, and check out to MyApp/ cd MyApp mkdir MyApp.egg-info echo "Name: MyApp Version: 0.0" > MyApp.egg-info/PKG-INFO echo "SQLObject>=0.6.1 pysqlite2 Cheetah" > MyApp.egg-info/depends.txt # But I'm going to be developing SQLObject, but not pysqlite and # Cheetah... svn co http://svn.colorstudy.com/trunk/SQLObject ../SQLObject cd ../SQLObject # Well, this isn't right, because SQLObject doesn't import # setuptools... I guess I have to run package/easy_install somehow? python setup.py bdist_egg cd .. export PYTHONPATH=`pwd` cd MyApp mkdir app-packages # What do I run here to get the dependencies that aren't already # fulfilled? easy_install -d app-packages (?) # But then I try to install pysqlite, but there's some weird conflict, # and I wish I was just using the OS package... so what do I do to # satisfy the dependency? Preferably without writing to # site-packages/, where pysqlite is installed? # and where are my scripts at this point? What should MyApp/setup.py # look like? What should MyApp/ look like? Should it have a package # underneath it? -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

EasyInstall: suggested usage patterns
by Ian Bicking June 16, 2005

June 16, 2005

Hi -- I'm getting ready to go out of town, so I haven't been able to track everything that's gone on in 0.4 (or 0.5 now?), and I might not be able to follow up on this conversation very thoroughly, but anyway... I feel like we need several suggested ways to use easy_install and eggs, given different cases. This is probably a documentation task; I'm more interested in how I *should* use this, rather than how I *can*. I guess that's the same as best practices. In turn I'd like to echo these best practices in any documentation or examples that use easy_install/eggs. Anyway, here's some cases: Development * I am developing an application. I don't have a distutil script for the application. * I am simultaneously developing distutils-based libraries. I want to edit these during my development process. * I also have some distutils libraries that I'm not developing, but I need to install. * I also have some libraries laying around that I already installed (before easy_install existed). And some that are from OS packages. * I have other Python stuff on my computer that I don't want to mess up because of my ongoing development. So, given this, what commands do I run? Where do I put files? What if I don't have permission to put files in global locations (site-packages)? How do I clean up after myself later? Later, this becomes... Deployment * I have developed a web application. Maybe it also doesn't have a distutils script...? It could, though currently I don't develop one for my web applications. Also, I sometimes make hot fixes, especially when the application is deployed but not yet live. * How and where should libraries be installed? How should application dependencies be expressed? * Some libraries are internal, and so aren't available from a public location. Maybe on the web with HTTP auth, though I'm more inclined to simply keep them in a branch in the private repository. Or fetch over scp. * Should I change my require()s to use a specific version of the libraries, so that I don't accidentally upgrade (/break) the application when a later application is installed? How do I manage that process? * Later a library might be broken and I need to fix it. Is there anything I should do on installation so I can later track who uses what library? Also so I can collect unused versions of libraries. Non-code * I'd like to distribute some data that doesn't have much (or maybe any) code. This might be a Javascript library, or a skin for the application (a bunch of templates and images), or something like that. Can I facilitate that with easy_install? Enabling plugins * I have library A, and library B. Library B optionally provides a "plugin" to library A, but both are usable in isolation. Library B needs to inject stuff into library A -- i.e., at runtime some code in library B enhances library A. How do I make this work? How do I make library A aware of library B? Other People's Code * Someone wrote some code I'd like to use. But it's poorly packaged -- maybe no setup.py, or maybe a bad one. For instance, I've decided that zpt.sf.net's setup.py is just broken -- you can't use extra_path, no package, and provide an __init__.py all at once. I'd like to write my own setup.py, but use that package. And it's on SF, so I'd like to use easy_install to download the package. Those are some of the things I'd like to do now -- easy_install doesn't have to magically make all of them work wonderfully; if I have to do things by hand, keep separate records, write custom code, or whatever, that's fine; I just want to know what I should be doing right now for each of these cases. Also, I'm interested in conventions we can define so that we all start doing the same thing. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 3

PATCH: setuptools-0.4a3 resource loading from egg problem
by Ryan Tomayko June 14, 2005

June 14, 2005

I've been getting the following when trying to use resource_filename when my package is in a zipped egg (since somewhere around 0.3a2 or so): Traceback (most recent call last): File "/usr/local/bin/somescript.py", line 4, in ? pkg_resources.run_main('somepackage==1.0', 'somescript.py') File "setuptools/pkg_resources.py", line 110, in run_main require(dist_spec)[0].metadata.run_script(script_name, __main__.__dict__) File "setuptools/pkg_resources.py", line 599, in run_script exec script_code in namespace, namespace File "/usr/local/bin/somescript.py", line 7, in ? File "egg/somepackage/somemodule.py", line 3, in ? File "setuptools/pkg_resources.py", line 388, in resource_filename return get_provider(package_name).get_resource_filename( File "setuptools/pkg_resources.py", line 728, in get_resource_filename return self._extract_resource(manager, resource_name) File "setuptools/pkg_resources.py", line 745, in _extract_resource zip_stat = self.zipinfo[os.path.join(*self.prefix+parts)] KeyError: 'somepackage/someresource.txt' Here's a test egg that illustrates the problem: <http://lesscode.org/eggs/somepackage-1.0-py2.4.egg> Install that and then run the included "somescript.py". You should see the traceback above. The problem seems to be with loading resources relative to a module in a package. The egg contains a package "somepackage" and a module within that package "somemodule". somemodule calls ``resource_filename (__name__, 'someresource.txt')``. The ZipProvider seems to handle this case badly. Attached is a patch against 0.4a3 that fixes this particular case but I'm not confident it won't cause problems elsewhere. I'll comment each hunk here with an explanation of what I think may be happening. @@ -573,7 +573,7 @@ def resource_listdir(self,resource_name): - return self._listdir(self._fn(self.egg_info,resource_name)) + return self._listdir(self._fn(self.module_path, resource_name)) def metadata_listdir(self,name): if self.egg_info: Here we see NullProvider.resource_listdir using [path]/EGG_INFO instead of [path]. This seems like a simple typo to me as there are resource_XXX and metadata_XXX methods, the first based on the module path and the second set based on the EGG_INFO dir. @@ -703,7 +703,7 @@ def __init__(self, module): DefaultProvider.__init__(self,module) self.zipinfo = zipimport._zip_directory_cache [self.loader.archive] - self.zip_pre = self.loader.archive+os.sep + self.zip_pre = self.module_path + os.sep def _short_name(self, path): if path.startswith(self.zip_pre): This is where I was a bit shaky: loader_archive = /path/to/the-egg.egg module_path = /path/to/the-egg.egg/package Shouldn't resource loading be relative to the package directory and not the root of the egg? @@ -738,7 +738,7 @@ def _extract_resource(self, manager, resource_name): if self.resource_isdir(resource_name): - return self._extract_dir(resource_name) + return self._extract_directory(manager, resource_name) parts = resource_name.split('/') zip_path = os.path.join(self.module_path, *parts) I believe this was a simple typo / refactoring-miss. This isn't breaking the test case but is causing problems in another package that is using resource_filename to get a directory. Thanks, Ryan Tomayko rtomayko(a)gmail.com http://naeblis.cx/rtomayko/

2 5

setuptools-0.4a2: Eggs, scripts, and __file__
by Ryan Tomayko June 14, 2005

June 14, 2005

From "[Distutils] A plan for scripts (in EasyInstall)" <http://mail.python.org/pipermail/distutils-sig/2005-June/004594.html> On Mon Jun 6 16:44:19 CEST 2005, Phillip J. Eby wrote: > The 'run_main' function would do several things: <snip> > > * Clear everything but __name__ from the __main__ namespace <snip> > * exec the script in __main__, using something like: > > maindict['__file__'] = pseudo_filename code = > compile(script_source, pseudo_filename, "exec") exec code in > maindict, maindict It seems that bullet one is happening but not bullet two? I have scripts that are attempting to use __file__ but failing with: NameError: name '__file__' is not defined The script looks like it would work properly if it was given a pseudo filename but this has me thinking about what the best way to detect development environments in scripts will look like in an eggified environment. My wrapper scripts generally look something like the following to detect whether the script is being run from a development location or a deployed location:: import sys from os.path import dirname, abspath, join, exists devel_dir = dirname(dirname(abspath(__file__))) if exists(join(devel_dir, 'support')): sys.path.insert(1, join(devel_dir, 'support')) sys.path.insert(1, devel_dir) from package.module import main main(sys.argv) Assuming a directory layout of: [devel-dir]/bin (scripts in here) [devel-dir]/support (packages/modules) [devel-dir]/[package-name] At first I thought I should switch from using path operations on __file__ to using `pkg_resources.resource_isdir` and `resource_filename` but that doesn't make any sense - if the script is running from within a deployed egg, I'm not using it from a development environment and the resource_*** functions don't make sense in __main__ context anyway. So my current thinking is that the existing idiom should remain and that a pseudo filename shouldn't pose any problems in the scenarios I'm dealing with: * Deployed egg: don't tamper with sys.path * Deployed site-packages: don't tamper with sys.path * Development environment: insert development paths At any rate, I'm guessing that __file__ appears in a good percentage of scripts in the wild. I've switched mine to use sys.argv[0] in place of __file__ but I'll see if I can get a patch together for getting a psuedo __file__ into the exec dict (but don't wait up - I'm not familiar with the code and figuring out how to get the psuedo filename will take me infinite orders of magnitude longer than you ;) Ryan Tomayko rtomayko(a)gmail.com http://naeblis.cx/rtomayko/

2 6

PATCH: setuptools-0.4a2 resource_filename prob
by Ryan Tomayko June 14, 2005

June 14, 2005

Ran into a minor issue with resource_filename: Traceback (most recent call last): File "pkg_resources.py", line 388, in resource_filename File "pkg_resources.py", line 728, in get_resource_filename File "pkg_resources.py", line 740, in _extract_resource File "pkg_resources.py", line 569, in resource_isdir NameError: global name 'resource_name' is not defined One liner: Index: pkg_resources.py =================================================================== RCS file: /cvsroot/python/python/nondist/sandbox/setuptools/ pkg_resources.py,v retrieving revision 1.29 diff -u -r1.29 pkg_resources.py --- pkg_resources.py 12 Jun 2005 21:47:33 -0000 1.29 +++ pkg_resources.py 13 Jun 2005 23:26:44 -0000 @@ -566,7 +566,7 @@ return yield_lines(self.get_metadata(name)) def resource_isdir(self,name): - return self._isdir(self._fn(self.module_path, resource_name)) + return self._isdir(self._fn(self.module_path, name)) def metadata_isdir(self,name): return self.egg_info and self._isdir(self._fn (self.egg_info,name)) Ryan Tomayko rtomayko(a)gmail.com http://naeblis.cx/rtomayko/

2 2