On Nov 7, 2007 1:52 AM, Gael Varoquaux <gae...@no...> wrote: > On Tue, Nov 06, 2007 at 09:00:23PM -0500, Darren Dale wrote: > > I have not committed my work to svn yet. I wanted to get some feedback on > > points 1 and 2 first. Is it acceptable to use traits internally, but not > > expose it to the end user? I think the answer is yes, and that this is even a > > benefit. If we want to make it an external dependency we can strip the > > package out without impacting any user code. > > I agree that by itself this is a benefit. It might also be interesting to > discuss this usecase on the enthought mailing list. If you tell these > guys that this is an important usecase, that projects like ipython, > matplotlib, would like to use traits as an internal dependency, but would > still like to be able to use the benefit of traits when interfacing with > other libraries, there might be a solution. I am not wild on the idea of an "internal dependency". Since this is the first step in providing traitified mpl properties, and users will presumably want to be able to set event handlers on these properties, etc, it seems best to me if the users are exposed to a proper installation of enthought traits. Is there a reason not to treat traits like we do dateutil and pytz: check at runtime if it is installed and if not install it as enthought.traits using Gael's tarball? If traits is already installed and the version is too old, complain and fail figuring if users have installed it before, they have the wherewithall to upgrade. This gets enthought.traits (preferably with traits.ui included) on more platforms. Ideally we would set up our install to play nicely with packagers like debian, so they can get dateutil, pytz and enthought.traits through their normal dependency handlers. We are simply trying to keep the barrier of installation as low as possible for the typical mpl user. JDH JDH