On Sunday 11 November 2007 7:08:38 pm Andrew Straw wrote:
> Eric Firing wrote:
> > Darren Dale wrote:
> >> 3) We can not include traits-3 without either adding setuptools as an
> >> external dependency (which is already true for python-2.3 users) or
> >> monkey-patching distutils. traits-3 includes
Eric Firing wrote:
> Darren Dale wrote:
>
>
>> 3) We can not include traits-3 without either adding setuptools as an
>> external
>> dependency (which is already true for python-2.3 users) or monkey-patching
>> distutils. traits-3 includes some pyrex code, which standard distutils does
>> not
On Nov 8, 2007 7:10 AM, Darren Dale <[EMAIL PROTECTED]> wrote:
> Fernando, do you have a record of the changes you guys made at SciPy-2007?
No, we just went through the codebase by hand and quickly removed
anything that looked like it would do namespace packages. Once that
was out of the way, th
On Thursday 08 November 2007 03:16:14 am Eric Firing wrote:
> Darren Dale wrote:
> > Building does not seem to be a problem, just do the usual python setup.py
> > build, etc. I ran backend_driver on my not-so-speedy home computer:
>
> Darren,
>
> Well done! I blew away other versions of traits, up
Darren Dale wrote:
> Building does not seem to be a problem, just do the usual python setup.py
> build, etc. I ran backend_driver on my not-so-speedy home computer:
Darren,
Well done! I blew away other versions of traits, updated mpl, built and
installed, and traits appeared. No pain.
The n
On Wednesday 07 November 2007 3:54:36 pm Darren Dale wrote:
> On Wednesday 07 November 2007 03:34:18 pm Eric Firing wrote:
> > Darren Dale wrote:
> > > I have been working on updating the trunk to provide enthought.traits
> > > version 2.6b1. backend_driver.py is running without exceptions using
>
On Wednesday 07 November 2007 03:34:18 pm Eric Firing wrote:
> Darren Dale wrote:
> > I have been working on updating the trunk to provide enthought.traits
> > version 2.6b1. backend_driver.py is running without exceptions using the
> > traited config package with the internal traits package.
> >
>
On Wed, Nov 07, 2007 at 10:34:18AM -1000, Eric Firing wrote:
> 1) If an internal version of traits is to be used, how hard would it be
> to patch it in such a way that it *could* be used externally?
I think pretty hard, but you would have to ask enthought's dev.
> 2) Does Gael's version already
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 fir
Darren Dale wrote:
> I have been working on updating the trunk to provide enthought.traits version
> 2.6b1. backend_driver.py is running without exceptions using the traited
> config package with the internal traits package.
>
> Issues:
>
> 1) there are lots of absolute package imports scattere
On Nov 7, 2007, at 12:08 PM, Darren Dale wrote:
>> I don't see the check-then-tarball as a feature, but as a significant
>> complication that I have to be aware of when I'm building MatPlotLib.
>
> Does the way matplotlib handles pytz and datetime present significant
> complications as well?
>
>>
Darren Dale wrote:
> Does the way matplotlib handles pytz and datetime present significant
> complications as well?
not too bad, but pytz and datetime are already pretty easy to install,
self-contained packages.
> But not all systems have a package manager, and not all package managers have
>
On Nov 7, 2007, at 12:04 PM, John Hunter wrote:
On Nov 7, 2007 12:01 PM, Boyd Waters <[EMAIL PROTECTED]> wrote:
Tell them they need a "real" enthought traits package. Then they can
use their package management to make it right.
This is of course assuming their package management has
enthoug
> But not all systems have a package manager, and not all package managers have
> support for traits.
Does *anything* or does *anyone* outside of enthought actually support
traits now? I know Fernando has said he is sold on it for ipython, but
I did not see it in the latest release.
While I
On Wednesday 07 November 2007 10:08:01 am william ratcliff wrote:
> And again, if MPL becomes "traitified", how will that effect users
> that need to roll executables for distribution?
We are considering changes that would require testing before we actually made
a release that would effect users.
On Wednesday 07 November 2007 01:01:52 pm Boyd Waters wrote:
> On Nov 7, 2007, at 7:25 AM, John Hunter wrote:
> > 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?
>
> I
On Nov 7, 2007 12:01 PM, Boyd Waters <[EMAIL PROTECTED]> wrote:
> Tell them they need a "real" enthought traits package. Then they can
> use their package management to make it right.
This is of course assuming their package management has
enthought.traits, which by and large, it won't.
I am sym
On Nov 7, 2007, at 7:25 AM, John Hunter wrote:
> 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?
I don't see the check-then-tarball as a feature, but as a significant
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 t
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 depende
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 t
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
> be
I have been working on updating the trunk to provide enthought.traits version
2.6b1. backend_driver.py is running without exceptions using the traited
config package with the internal traits package.
Issues:
1) there are lots of absolute package imports scattered throughout traits'
code. I wor
23 matches
Mail list logo
