On Wednesday 07 November 2007 09:25:51 am John Hunter wrote: > On Nov 7, 2007 1:52 AM, Gael Varoquaux <[EMAIL PROTECTED]> 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.
I will try this approach tonight. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
