And again, if MPL becomes "traitified", how will that effect users that need to roll executables for distribution?
On Nov 7, 2007 9:39 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------------------------- 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
