[Distutils] requiring python 2.5

[Bryce Hendrix]

Rick,

We require setuptools >=0.7.0 for windows anyway, if that makes any 
difference...

Bryce

Rick Ratzel wrote:
>    Arg...I thought I had this working, but it turns out I had a setuptools 0.7
> dev release installed.  When I go to a setuptools 0.6 release, I get the same
> old problem.  Here are more details...
>
>    Enstaller is started with a script generated when easy_install installs the
> egg, so right away pkg_resources is imported and I have no chance to do anything
> before.  I put the following in enstaller's __init__.py as recommended:
>
> from os import path
> import enthought
> enthought.__path__ = [path.dirname( path.dirname( __file__ ) )]
>
>    and confirmed that it is indeed setting the __path__ for enthought correctly
> with a "print enthought.__path__" in another enstaller module imported later,
> which produced:
>
> ['c:\\python25\\lib\\site-packages\\enstaller-2.1.0b1-py2.5-win32.egg\\enthought']
>
>    This is compared to the two screenfuls of 'enthought.' paths without that
> code.  As mentioned, this works great for setuptools 0.7, but as soon as I
> switch out 0.7 for 0.6, I get ImportErrors from package mismatches as python
> finds other incompatible 'enthought.' packages on the system instead of the ones
> bundled in the enstaller egg.  If I leave the above code out completely, neither
> 0.6 or 0.7 work (as expected).
>
>    Can you point out what, if anything, I'm doing wrong, since I thought setting
> enthought.__path__ is supposed to work with 0.6?
>
>    I think I have three options at this point: 
>
> 1.) have enstaller require setuptools>=0.7 (which enthought is hosting and will
>   be found automatically by the enstaller install script)
>
> 2.) write a function in the enstaller egg build script that bundles all the
>   packages into a namespace other than 'enthought.' inside of the egg, say
>   'bundle.' for example, and does a global search-and-replace of 'enthought.'
>   with 'bundle.'  Assuming the script gets everything, this seems like it would
>   be the most straightforward and would not require me to fiddle with the
>   python/setuptools import machinery.
>
> 3.) find the silly mistake I made which is causing the initial fix to break for
>   0.6, if possible.
>
>    Thanks in advance!
>
>
>   
>>    Date: Sat, 09 Jun 2007 16:04:45 -0400
>>    From: "Phillip J. Eby" <pje at telecommunity.com>
>>
>>    At 09:26 PM 6/8/2007 -0500, Rick Ratzel wrote:
>>
>>    >    Is there a way to have my package tell setuptools to "ignore" 
>>    > certain other
>>    >packages?
>>
>>    Only through version specifications; i.e., request the exact versions you want.
>>
>>
>>    >    I've tried removing all the "enthought." eggs from sys.path 
>>    > before anything
>>    >else gets imported, but even that doesn't work (and it just felt wrong, and
>>    >probably is).
>>
>>    If "enthought" is a namespace package, you would need to either be 
>>    using an 0.7-development version of setuptools (i.e., a trunk SVN 
>>    version), or else you'd need to remove those eggs from the path 
>>    *before* pkg_resources is first imported.  Otherwise, it would indeed not work.
>>
>>
>>    >I looked at the docs for manipulating the WorkingSet, but made no
>>    >progress there either...python always managed to find the incompatible
>>    >enthought.traits code in the enthought.traits egg.  When I remove the
>>    >incompatible enthought.traits, all works fine.
>>    >
>>    >    What I'd like to do is simply say "do not use any enthought.* 
>>    > eggs".  Is this
>>    >possible?  Thanks in advance!
>>
>>    Not without using an 0.7 version of setuptools, or manipulating 
>>    enthought.__path__.  The straightforward way to do it would be for 
>>    enstaller's __init__.py to do this:
>>
>>        import enthought, os
>>        enthought.__path__ = os.path.dirname(os.path.dirname(__file__))
>>
>>    This will ensure that all enthought.* modules imported from then on 
>>    will only be from within the parent directory of enstaller.
>>
>>    I don't think I'd recommend this to anyone in the general case, but 
>>    this might be a reasonable workaround if you truly want to 
>>    "de-namespace" the package.  (It will *not*, however, prevent new 
>>    eggs from being added to __path__ if you add anything to sys.path or 
>>    the working set afterward.)
>>
>>
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20070614/feef40c3/attachment.html