This option controls where the .egg-info *build* directory will be and *nothing* else

Yes. :-) Did you notice, in my unfortunately long initial post, the issue I had with script generation when the build directory was in a non default location ? egg_base=./ seemed to prevent the installation of console_scripts. I'm planing on spending today attempting a test case patch to show this. You'd save me some time if you could say "this is not a bug" :-) [apologies, quoting you in reverse order here]

I'll look into this option in setuptools 0.7, although I think it will also require some work on the install_data command. There's also a potentially significant limitation in that you won't be able to look up non-package resources using package names. That is, you're not going to be able to do resource_filename('foo.bar', '/baz'). Instead, you would have to do resource_filename(Requirement.parse('MyProject'), '/baz').

I don't think this is a limitation. As the package author I have gone to some trouble to say "this data is not package data". I would not then expect (or want) to be able to reference that data using the ``package`` bit of ``resouce_string(package_or_requirement, resource_name)``. If resource_name referes to non package data then I *expect* Requirement.parse('MyProject') to be its name space when referenced by my program.

Meanwhile, I think the solution to your overall problem will require either expanding the metadata API to allow file access, or else adding some kind of path facility to the resource API (e.g. '/'-prefixed paths as you suggested) to access a 'data/' subdirectory of the egg-info directory.

Yes, I agree. I'll have a stab at thinking this through: (Aside: I think it's a *good* thing that eggs don't attempt to be a 'full blown' virtualised file system - that would involve too much magic for my tastes, refactored or not ;-). There are at least two 'file' systems in play here: the package authors development source tree and the eggs collection of resource_names. All information to produce the latter is available, or could be available, to setuptools once ``python setup.py egg_info`` has run. A key advantage (for me at least) of ``python setup.py develop`` is that it produces the .egg-info directory but does *not* trigger a full build of my sources. Specifically, it is most advantageous where my source tree has a lot of data that would otherwise be copied into the build tree. Being able to avoid this copy and still run something that is pretty close to what my end users will run is *very* cool. It would be a shame to loose this for non packaged data files. Which suggests that .egg-info would need to remember enough information about the source tree in order to allow pkg_resources to perform a reverse mapping for resource_filename(Requirement.parse('MyProject'), '/baz') I can not see a reasonable way to support: python lib/MyProject/entrypoint.py --list-non-packaged-data. Ie, expecting pkg_resources to perform this reverse mapping *before* .egg-info is built. If python setup.py develop does *not* copy data_files into place, I don't think it's unreasonable for pkg_resources to assume EGG-INFO is always available. For all 'installed' cases I think setuptools can get at EGG-INFO without guess work. For python setup.py develop, I think heuristics in pkg_resources, that look for .egg-info relative to MyPackage are acceptable. boost bjam does something allong these lines when it looks for boost-build.jam. The confusion I had initially with egg_base was that I guessed (incorrectly) that it could be used as a way to preserve the 'prefix' information and make it available in the resultant .egg-info. I find my self *really* wanting to help get this into 0.7. I have both the time and the need to work on this. I'm happy to have a stab blind and contribute the results. Alternately, if you spec it, I'd have no trouble letting you direct my typing fingers :-) Cheers, Robin