On Wed, Nov 07, 2007 at 08:25:51AM -0600, John Hunter wrote: > 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.
I agree with that. This would clearly be a temporary solution waiting for better packaging of 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? This does not seem a terribly good solution. First of all, I assume you mean install time rather than run-time, as I can't see this happening at run-time for a question of permission. Package management is not such an easy task, as the endeavour of setup_tools has shown. Of course the solution for platforms with proper package managers, is to use this package manager, but when there isn't one, try to provide one, even a simple one, is a risky endeavour. If you are going to try to do this, I would try to do it through setuptools, maybe by including the relevant code from setuptools in MPL. Then there is the problem of compiling. Traits has a bit of compiled code, and not everybody has a compiler installed. So you have to provide binary packages for the major platforms. This also points towards eggs, as eggs are binary packages (eggs are nothing more than a zipped python package), and we are already building binary eggs for traits and Co. > This gets enthought.traits (preferably with traits.ui included) on > more platforms. Yes, the big and important work is to get traits and traitsUI packaged natively on more platforms. Ondrej Certik has started debian packages, but he does not have much time to work on them, and they are progressing slowly. Some people have offered packaging for Fedora, but the problem is the same. If you know people who are willing to do some packaging work, we need some help :->. > We are simply trying to keep the barrier of installation as low as > possible for the typical mpl user. This is very important, indeed. Can you tell us a bit more what you plan to use traits for exactly (what are the usecases) ? It might help me understand how to find a beautiful solution to this chicken and eggs problem. Gaël ------------------------------------------------------------------------- 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
