[Distutils] "ignoring" eggs (was: Re: requiring python 2.5)

[Rick Ratzel]

(sorry about the subject line...I meant to start a new thread)

   Phillip,

   Thanks for the response.  I implemented your recommendation and it did
exactly what I needed it to do.  More comments inline:


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

   Yep, that's initially what I wanted to do since it was the "standard" way to
do it.  Unfortunatley, the packages that enstaller required were just recently
"egg'd", and most of them had broken dependencies and stale version numbers.
Many of the interdependencies did not even specify versions, so an old,
incompatible version that was already installed satisfied the dependency but
left enstaller broken.  Many of the packages are now fixed (we've been
undergoing a huge effort to convert our OSS repository to an egg-based
deployment), but I was later convinced that it might be a good idea to keep
enstaller isolated from the other eggs.  Plus, enstaller[gui] requires about 13
eggs, almost all of which are used by other projects too.  Users would
"uninstall" their eggs and not realize that they were breaking enstaller.

   The monolithic egg approach seems to have solved all these problems.
Unfortunately the eggs are obviously much bigger and downloading will be more
expensive, especially for the enstaller.gui egg, which is installed by default
by a bootstrapping script.


>    >    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 ended up setting enthought.__path__ like you suggested, and will probably
stick with that rather than force users to upgrade to 0.7 right now.  However,
I'm curious about how this is addressed in 0.7.  Is there a new API for doing
this?


>    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.)


   Right.  Fortunately, all the path "magic" is contained to this change, so I
should be safe.  Thanks again,


-- 
Rick Ratzel - Enthought, Inc.
515 Congress Avenue, Suite 2100 - Austin, Texas 78701
512-536-1057 x229 - Fax: 512-536-1059
http://www.enthought.com