ETS Sprints Report

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

ETS Sprints Report

Anthony Scopatz
Hello All, 

I am pleased to report that the ETS Sprints this weekend went very well.  

In Austin we had,:
  • Ilan Schnell
  • Kevin Lam
  • Alfredo Miranda
  • Jonathan Rocher
  • John Wiggins
Remotely we had:
  • Varun Hiremath
  • Gael Varoquaux
Some of the topics we worked on were updating Traits/Examples/, 
improving chaco documentation, adding redirects to new ETS docs
from deprecated pages on various websites, teaching the new people
Traits and Chaco, and started migrating issue tracking from Trac
to GitHub's Issues 2.0.

Additionally, Ilan and I (and John) spent a lot of time talking about 
how to migrate from 

'from enthought.traits.api import ...'

to simply 

'from traits import ...'

From here on, I'll call this the namespace issue.   As you know it applies 
to all of the ETS packages, but we decided to focus on Traits first, since 
it is the most embedded.  

In the short term we will be providing aliases so that old code doesn't break.  
That is to say, along with the namespace migration there will be a mapping
such that 'enthought.traits.api' points to 'traits'.  These aliases are due for 
removal at Traits 4.

The easiest and correct way to fix this issue is to not have multiple 
packages write into the same namespace.  Therefore the goal should be to 
have 1 namespace per package.  Currently, here is what we propose for the 
package/namespace dependencies, in the finest ASCII art I can muster.
Parentheses contain where code lives currently

traits (traits, enthoughtbase)
   |
pyface (traitsgui, traitsbackends)
   |
traitsui (traits.ui, traitsgui, traitsbackends)

So we would be removing the enthoughtbase package (and as Scott put it, 
admitting that everything lives on top of Traits) by migrating its code into 
traits. 

We will also remove traitsgui and the backends, migrating their code into the 
new traitsui and pyface packages as appropriate.   This would also mean that
traits.ui no longer exists.

Additionally, we would add a separate etsproxy package, that can optionally 
add proxies back to the old namespace if installed.

Refactoring other package's namespace issues such as enable, kiva, chaco, 
mayavi, etc. may follow.

Since this is a major undertaking, we wanted to give everyone a chance to 
respond or field their concerns.   If there are no critical errors in our thinking
here, we'll go ahead and perform the fix in the next couple of days.

Hopefully this will make ETS that much easier to use!
Be Well
Anthony

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Ilan Schnell
Thanks for organizing the ETS sprint and for writing up the
namespace problems/solution.  As I've already done some
namespace renaming during the sprint, I'll be happy to finish
the task following the diagram.

- Ilan


On Mon, Apr 18, 2011 at 5:02 PM, Anthony Scopatz <[hidden email]> wrote:

> Hello All,
> I am pleased to report that the ETS Sprints this weekend went very well.
> In Austin we had,:
>
> Ilan Schnell
> Kevin Lam
> Alfredo Miranda
> Jonathan Rocher
> John Wiggins
>
> Remotely we had:
>
> Varun Hiremath
> Gael Varoquaux
>
> Some of the topics we worked on were updating Traits/Examples/,
> improving chaco documentation, adding redirects to new ETS docs
> from deprecated pages on various websites, teaching the new people
> Traits and Chaco, and started migrating issue tracking from Trac
> to GitHub's Issues 2.0.
> Additionally, Ilan and I (and John) spent a lot of time talking about
> how to migrate from
>
> 'from enthought.traits.api import ...'
> to simply
> 'from traits import ...'
>
> From here on, I'll call this the namespace issue.   As you know it applies
> to all of the ETS packages, but we decided to focus on Traits first, since
> it is the most embedded.
> In the short term we will be providing aliases so that old code doesn't
> break.
> That is to say, along with the namespace migration there will be a mapping
> such that 'enthought.traits.api' points to 'traits'.  These aliases are due
> for
> removal at Traits 4.
> The easiest and correct way to fix this issue is to not have multiple
> packages write into the same namespace.  Therefore the goal should be to
> have 1 namespace per package.  Currently, here is what we propose for the
> package/namespace dependencies, in the finest ASCII art I can muster.
> Parentheses contain where code lives currently
>
> traits (traits, enthoughtbase)
>    |
> pyface (traitsgui, traitsbackends)
>    |
> traitsui (traits.ui, traitsgui, traitsbackends)
>
> So we would be removing the enthoughtbase package (and as Scott put it,
> admitting that everything lives on top of Traits) by migrating its code
> into
> traits.
> We will also remove traitsgui and the backends, migrating their code into
> the
> new traitsui and pyface packages as appropriate.   This would also mean that
> traits.ui no longer exists.
> Additionally, we would add a separate etsproxy package, that can optionally
> add proxies back to the old namespace if installed.
> Refactoring other package's namespace issues such as enable, kiva, chaco,
> mayavi, etc. may follow.
> Since this is a major undertaking, we wanted to give everyone a chance to
> respond or field their concerns.   If there are no critical errors in our
> thinking
> here, we'll go ahead and perform the fix in the next couple of days.
> Hopefully this will make ETS that much easier to use!
> Be Well
> Anthony
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Jonathan Rocher
Just a quick additional note: as part of the effort to improve our documentation and accessibility of information, during the sprint I created a place to report broken or inappropriate links on the Enthought website:
https://docs.google.com/a/enthought.com/document/d/1L3DAhK01ykib4euKu7FXUoegs-8rExtoHOxaGfe-4Xo/edit?hl=en#

Thanks in advance for reporting if you find some.

Best,
Jonathan

On Mon, Apr 18, 2011 at 5:12 PM, Ilan Schnell <[hidden email]> wrote:
Thanks for organizing the ETS sprint and for writing up the
namespace problems/solution.  As I've already done some
namespace renaming during the sprint, I'll be happy to finish
the task following the diagram.

- Ilan


On Mon, Apr 18, 2011 at 5:02 PM, Anthony Scopatz <[hidden email]> wrote:
> Hello All,
> I am pleased to report that the ETS Sprints this weekend went very well.
> In Austin we had,:
>
> Ilan Schnell
> Kevin Lam
> Alfredo Miranda
> Jonathan Rocher
> John Wiggins
>
> Remotely we had:
>
> Varun Hiremath
> Gael Varoquaux
>
> Some of the topics we worked on were updating Traits/Examples/,
> improving chaco documentation, adding redirects to new ETS docs
> from deprecated pages on various websites, teaching the new people
> Traits and Chaco, and started migrating issue tracking from Trac
> to GitHub's Issues 2.0.
> Additionally, Ilan and I (and John) spent a lot of time talking about
> how to migrate from
>
> 'from enthought.traits.api import ...'
> to simply
> 'from traits import ...'
>
> From here on, I'll call this the namespace issue.   As you know it applies
> to all of the ETS packages, but we decided to focus on Traits first, since
> it is the most embedded.
> In the short term we will be providing aliases so that old code doesn't
> break.
> That is to say, along with the namespace migration there will be a mapping
> such that 'enthought.traits.api' points to 'traits'.  These aliases are due
> for
> removal at Traits 4.
> The easiest and correct way to fix this issue is to not have multiple
> packages write into the same namespace.  Therefore the goal should be to
> have 1 namespace per package.  Currently, here is what we propose for the
> package/namespace dependencies, in the finest ASCII art I can muster.
> Parentheses contain where code lives currently
>
> traits (traits, enthoughtbase)
>    |
> pyface (traitsgui, traitsbackends)
>    |
> traitsui (traits.ui, traitsgui, traitsbackends)
>
> So we would be removing the enthoughtbase package (and as Scott put it,
> admitting that everything lives on top of Traits) by migrating its code
> into
> traits.
> We will also remove traitsgui and the backends, migrating their code into
> the
> new traitsui and pyface packages as appropriate.   This would also mean that
> traits.ui no longer exists.
> Additionally, we would add a separate etsproxy package, that can optionally
> add proxies back to the old namespace if installed.
> Refactoring other package's namespace issues such as enable, kiva, chaco,
> mayavi, etc. may follow.
> Since this is a major undertaking, we wanted to give everyone a chance to
> respond or field their concerns.   If there are no critical errors in our
> thinking
> here, we'll go ahead and perform the fix in the next couple of days.
> Hopefully this will make ETS that much easier to use!
> Be Well
> Anthony
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



--
Jonathan Rocher, PhD
Scientific software developer
Enthought, Inc.
[hidden email]
1-512-536-1057
http://www.enthought.com



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Gael Varoquaux
In reply to this post by Anthony Scopatz
On Mon, Apr 18, 2011 at 05:02:32PM -0500, Anthony Scopatz wrote:
>    The easiest and correct way to fix this issue is to not have multiple
>    packages write into the same namespace. Therefore the goal should be to
>    have 1 namespace per package. Currently, here is what we propose for the
>    package/namespace dependencies, in the finest ASCII art I can muster.
>    Parentheses contain where code lives currently

>      traits (traits, enthoughtbase)
>  |
>      pyface (traitsgui, traitsbackends)
>         |
>      traitsui (traits.ui, traitsgui, traitsbackends)

>    So we would be removing the enthoughtbase package (and as Scott put it,
>    admitting that everything lives on top of Traits) by migrating its code
>    into traits.
>    We will also remove traitsgui and the backends, migrating their code into
>    the new traitsui and pyface packages as appropriate. This would also mean
>    that traits.ui no longer exists.

Awesome: less packages means easier to install, and no namespace packages
means less packaging bug in the distros!

One thing that I wonder, is if the pyface package could not be collapsed
under traitsui.pyface. Pyface is not used without traits, so having only
2 packages traits and traitsui would provide a really simple view on the
traits ecosystem that would easily make sens to people.

Lookin' great.

Gael
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Eraldo Pomponi
Dear All, 

Thank you very much for your effort to keep ETS as simple as possible to understand for everyone.
I would just say that I also agree with Gael about Pyface and traitsui. My 2 cent

Cheers, 
Eraldo 


On Tue, Apr 19, 2011 at 7:19 AM, Gael Varoquaux <[hidden email]> wrote:
On Mon, Apr 18, 2011 at 05:02:32PM -0500, Anthony Scopatz wrote:
>    The easiest and correct way to fix this issue is to not have multiple
>    packages write into the same namespace. Therefore the goal should be to
>    have 1 namespace per package. Currently, here is what we propose for the
>    package/namespace dependencies, in the finest ASCII art I can muster.
>    Parentheses contain where code lives currently

>      traits (traits, enthoughtbase)
>         |
>      pyface (traitsgui, traitsbackends)
>         |
>      traitsui (traits.ui, traitsgui, traitsbackends)

>    So we would be removing the enthoughtbase package (and as Scott put it,
>    admitting that everything lives on top of Traits) by migrating its code
>    into traits.
>    We will also remove traitsgui and the backends, migrating their code into
>    the new traitsui and pyface packages as appropriate. This would also mean
>    that traits.ui no longer exists.

Awesome: less packages means easier to install, and no namespace packages
means less packaging bug in the distros!

One thing that I wonder, is if the pyface package could not be collapsed
under traitsui.pyface. Pyface is not used without traits, so having only
2 packages traits and traitsui would provide a really simple view on the
traits ecosystem that would easily make sens to people.

Lookin' great.

Gael
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Anthony Scopatz
Hi Gael, Eraldo, 

Thanks for your support on the namespace issue.

 
I would just say that I also agree with Gael about Pyface and traitsui.

As I understand it, traitsui lives on top of pyface.  Additionally, other packages
(like enable) import from pyface but never touch traitsui.  So I think in the short term
that pyface has to stay.  

Be Well
Anthony

 
My 2 cent

Cheers, 
Eraldo 


On Tue, Apr 19, 2011 at 7:19 AM, Gael Varoquaux <[hidden email]> wrote:
On Mon, Apr 18, 2011 at 05:02:32PM -0500, Anthony Scopatz wrote:
>    The easiest and correct way to fix this issue is to not have multiple
>    packages write into the same namespace. Therefore the goal should be to
>    have 1 namespace per package. Currently, here is what we propose for the
>    package/namespace dependencies, in the finest ASCII art I can muster.
>    Parentheses contain where code lives currently

>      traits (traits, enthoughtbase)
>         |
>      pyface (traitsgui, traitsbackends)
>         |
>      traitsui (traits.ui, traitsgui, traitsbackends)

>    So we would be removing the enthoughtbase package (and as Scott put it,
>    admitting that everything lives on top of Traits) by migrating its code
>    into traits.
>    We will also remove traitsgui and the backends, migrating their code into
>    the new traitsui and pyface packages as appropriate. This would also mean
>    that traits.ui no longer exists.

Awesome: less packages means easier to install, and no namespace packages
means less packaging bug in the distros!

One thing that I wonder, is if the pyface package could not be collapsed
under traitsui.pyface. Pyface is not used without traits, so having only
2 packages traits and traitsui would provide a really simple view on the
traits ecosystem that would easily make sens to people.

Lookin' great.

Gael
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

bryce hendrix-2
On Tue, Apr 19, 2011 at 9:44 AM, Anthony Scopatz <[hidden email]> wrote:
Hi Gael, Eraldo, 

Thanks for your support on the namespace issue.

 
I would just say that I also agree with Gael about Pyface and traitsui.

As I understand it, traitsui lives on top of pyface.  Additionally, other packages
(like enable) import from pyface but never touch traitsui.  So I think in the short term
that pyface has to stay.  

I should clear up some of the fuzziness about TraitsUI/Pyface:

Some functionality in TraitsUI is dependent on Pyface, but not all. Some editors are written to use qt/wx controls, some use pyface controls. To complicate things even more, some code in TraitsUI uses Qt controls for the Qt toolkit, but pyface for the wx toolkit. The dock windows & table editor are two examples.

Pyface also provides some functionality that developers should use directly, such as error dialogs and timer related methods (do_later, etc).

Enable relies pretty heavily on TraitsUI, not so much of Pyface. The few direct uses of pyface could probably be refactored if needed.

Bryce

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Anthony Scopatz

On Tue, Apr 19, 2011 at 10:50 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 9:44 AM, Anthony Scopatz <[hidden email]> wrote:
Hi Gael, Eraldo, 

Thanks for your support on the namespace issue.

 
I would just say that I also agree with Gael about Pyface and traitsui.

As I understand it, traitsui lives on top of pyface.  Additionally, other packages
(like enable) import from pyface but never touch traitsui.  So I think in the short term
that pyface has to stay.  

I should clear up some of the fuzziness about TraitsUI/Pyface:

Some functionality in TraitsUI is dependent on Pyface, but not all. Some editors are written to use qt/wx controls, some use pyface controls. To complicate things even more, some code in TraitsUI uses Qt controls for the Qt toolkit, but pyface for the wx toolkit. The dock windows & table editor are two examples.

Pyface also provides some functionality that developers should use directly, such as error dialogs and timer related methods (do_later, etc).

Enable relies pretty heavily on TraitsUI, not so much of Pyface. The few direct uses of pyface could probably be refactored if needed.

So Bryce, do you think it is worth putting pyface into the enable namespace and getting rid of the pyface namespace?  It is more intuitive... 

Be Well
Anthony
 

Bryce

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Ilan Schnell
In reply to this post by bryce hendrix-2
Eric pointed out that the reason for having the api.py files, and
not defining the api in __init__.py, is to allow users to only import
a single submodule, without the api being executed (and thereby
importing all modules).
After doing some experimentation, it seems that it is not
straight-forward to import modules in a package and not
import the __init__.py file.
Threrfore we should keep the api modules, and leave __init__
modules empty.  However, as we are removing the namespace
packages, we can now have __version__ in those files.  This
was already proposed at the Enthought Institute by Peter, but
turned out to be unfeasable as the __init__modules are shared
by different packages.
Summary:
  * keep api.py files
  * have __version__ in __init__ when useful

- Ilan


On Tue, Apr 19, 2011 at 10:50 AM, bryce hendrix <[hidden email]> wrote:

> On Tue, Apr 19, 2011 at 9:44 AM, Anthony Scopatz <[hidden email]>
> wrote:
>>
>> Hi Gael, Eraldo,
>> Thanks for your support on the namespace issue.
>>
>>
>>>
>>> I would just say that I also agree with Gael about Pyface and traitsui.
>>
>> As I understand it, traitsui lives on top of pyface.  Additionally, other
>> packages
>> (like enable) import from pyface but never touch traitsui.  So I think in
>> the short term
>> that pyface has to stay.
>
> I should clear up some of the fuzziness about TraitsUI/Pyface:
> Some functionality in TraitsUI is dependent on Pyface, but not all. Some
> editors are written to use qt/wx controls, some use pyface controls. To
> complicate things even more, some code in TraitsUI uses Qt controls for the
> Qt toolkit, but pyface for the wx toolkit. The dock windows & table editor
> are two examples.
> Pyface also provides some functionality that developers should use directly,
> such as error dialogs and timer related methods (do_later, etc).
> Enable relies pretty heavily on TraitsUI, not so much of Pyface. The few
> direct uses of pyface could probably be refactored if needed.
> Bryce
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

bryce hendrix-2
In reply to this post by Anthony Scopatz
On Tue, Apr 19, 2011 at 11:46 AM, Anthony Scopatz <[hidden email]> wrote:

On Tue, Apr 19, 2011 at 10:50 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 9:44 AM, Anthony Scopatz <[hidden email]> wrote:
Hi Gael, Eraldo, 

Thanks for your support on the namespace issue.

 
I would just say that I also agree with Gael about Pyface and traitsui.

As I understand it, traitsui lives on top of pyface.  Additionally, other packages
(like enable) import from pyface but never touch traitsui.  So I think in the short term
that pyface has to stay.  

I should clear up some of the fuzziness about TraitsUI/Pyface:

Some functionality in TraitsUI is dependent on Pyface, but not all. Some editors are written to use qt/wx controls, some use pyface controls. To complicate things even more, some code in TraitsUI uses Qt controls for the Qt toolkit, but pyface for the wx toolkit. The dock windows & table editor are two examples.

Pyface also provides some functionality that developers should use directly, such as error dialogs and timer related methods (do_later, etc).

Enable relies pretty heavily on TraitsUI, not so much of Pyface. The few direct uses of pyface could probably be refactored if needed.

So Bryce, do you think it is worth putting pyface into the enable namespace and getting rid of the pyface namespace?  It is more intuitive... 


I'm not following, why would we put pyface in the enable namespace?

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Anthony Scopatz


On Tue, Apr 19, 2011 at 11:48 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 11:46 AM, Anthony Scopatz <[hidden email]> wrote:

On Tue, Apr 19, 2011 at 10:50 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 9:44 AM, Anthony Scopatz <[hidden email]> wrote:
Hi Gael, Eraldo, 

Thanks for your support on the namespace issue.

 
I would just say that I also agree with Gael about Pyface and traitsui.

As I understand it, traitsui lives on top of pyface.  Additionally, other packages
(like enable) import from pyface but never touch traitsui.  So I think in the short term
that pyface has to stay.  

I should clear up some of the fuzziness about TraitsUI/Pyface:

Some functionality in TraitsUI is dependent on Pyface, but not all. Some editors are written to use qt/wx controls, some use pyface controls. To complicate things even more, some code in TraitsUI uses Qt controls for the Qt toolkit, but pyface for the wx toolkit. The dock windows & table editor are two examples.


This line:
 
Pyface also provides some functionality that developers should use directly, such as error dialogs and timer related methods (do_later, etc).

seems to contradict this line:

Enable relies pretty heavily on TraitsUI, not so much of Pyface. The few direct uses of pyface could probably be refactored if needed.

in the sense that shouldn't enable be refactored to use *more* of pyface?

That is why I was confused before and misread what you were saying.  I am fine with keeping the pyface namespace.  Sorry.

Be Well
Anthony
 

So Bryce, do you think it is worth putting pyface into the enable namespace and getting rid of the pyface namespace?  It is more intuitive... 


I'm not following, why would we put pyface in the enable namespace?

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Evan Patterson
In reply to this post by bryce hendrix-2

On Apr 19, 2011, at 11:48 AM, bryce hendrix wrote:

On Tue, Apr 19, 2011 at 11:46 AM, Anthony Scopatz <[hidden email]> wrote:

On Tue, Apr 19, 2011 at 10:50 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 9:44 AM, Anthony Scopatz <[hidden email]> wrote:
Hi Gael, Eraldo, 

Thanks for your support on the namespace issue.

 
I would just say that I also agree with Gael about Pyface and traitsui.

As I understand it, traitsui lives on top of pyface.  Additionally, other packages
(like enable) import from pyface but never touch traitsui.  So I think in the short term
that pyface has to stay.  

I should clear up some of the fuzziness about TraitsUI/Pyface:

Some functionality in TraitsUI is dependent on Pyface, but not all. Some editors are written to use qt/wx controls, some use pyface controls. To complicate things even more, some code in TraitsUI uses Qt controls for the Qt toolkit, but pyface for the wx toolkit. The dock windows & table editor are two examples.

Pyface also provides some functionality that developers should use directly, such as error dialogs and timer related methods (do_later, etc).

Enable relies pretty heavily on TraitsUI, not so much of Pyface. The few direct uses of pyface could probably be refactored if needed.

So Bryce, do you think it is worth putting pyface into the enable namespace and getting rid of the pyface namespace?  It is more intuitive... 


I'm not following, why would we put pyface in the enable namespace?

Yes, Pyface does not depend on Traits UI and is useful in its own right. It should have its own top-level package.

Evan

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

bryce hendrix-2
In reply to this post by Anthony Scopatz
On Tue, Apr 19, 2011 at 11:57 AM, Anthony Scopatz <[hidden email]> wrote:


On Tue, Apr 19, 2011 at 11:48 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 11:46 AM, Anthony Scopatz <[hidden email]> wrote:

On Tue, Apr 19, 2011 at 10:50 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 9:44 AM, Anthony Scopatz <[hidden email]> wrote:
Hi Gael, Eraldo, 

Thanks for your support on the namespace issue.

 
I would just say that I also agree with Gael about Pyface and traitsui.

As I understand it, traitsui lives on top of pyface.  Additionally, other packages
(like enable) import from pyface but never touch traitsui.  So I think in the short term
that pyface has to stay.  

I should clear up some of the fuzziness about TraitsUI/Pyface:

Some functionality in TraitsUI is dependent on Pyface, but not all. Some editors are written to use qt/wx controls, some use pyface controls. To complicate things even more, some code in TraitsUI uses Qt controls for the Qt toolkit, but pyface for the wx toolkit. The dock windows & table editor are two examples.


This line:
 
Pyface also provides some functionality that developers should use directly, such as error dialogs and timer related methods (do_later, etc).

seems to contradict this line:

Enable relies pretty heavily on TraitsUI, not so much of Pyface. The few direct uses of pyface could probably be refactored if needed.


Ah, yes, Enable does rely on Pyface via a strong dependency on TraitsUI, but does not directly use pyface modules more than a handful of times.
 
in the sense that shouldn't enable be refactored to use *more* of pyface?

No, Enable uses TraitsUI to provide ComponentEditor, SvgButtonEditor and code to support colors and fonts. There isn't much in Pyface that Enable would ever want to explicitly use. If you grep through the code, you'll see it 2 direct uses of pyface- one for a timer object to determine when to pop up the hover window, and the other for a menu.

Bryce

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Anthony Scopatz


On Tue, Apr 19, 2011 at 12:18 PM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 11:57 AM, Anthony Scopatz <[hidden email]> wrote:


On Tue, Apr 19, 2011 at 11:48 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 11:46 AM, Anthony Scopatz <[hidden email]> wrote:

On Tue, Apr 19, 2011 at 10:50 AM, bryce hendrix <[hidden email]> wrote:
On Tue, Apr 19, 2011 at 9:44 AM, Anthony Scopatz <[hidden email]> wrote:
Hi Gael, Eraldo, 

Thanks for your support on the namespace issue.

 
I would just say that I also agree with Gael about Pyface and traitsui.

As I understand it, traitsui lives on top of pyface.  Additionally, other packages
(like enable) import from pyface but never touch traitsui.  So I think in the short term
that pyface has to stay.  

I should clear up some of the fuzziness about TraitsUI/Pyface:

Some functionality in TraitsUI is dependent on Pyface, but not all. Some editors are written to use qt/wx controls, some use pyface controls. To complicate things even more, some code in TraitsUI uses Qt controls for the Qt toolkit, but pyface for the wx toolkit. The dock windows & table editor are two examples.


This line:
 
Pyface also provides some functionality that developers should use directly, such as error dialogs and timer related methods (do_later, etc).

seems to contradict this line:

Enable relies pretty heavily on TraitsUI, not so much of Pyface. The few direct uses of pyface could probably be refactored if needed.


Ah, yes, Enable does rely on Pyface via a strong dependency on TraitsUI, but does not directly use pyface modules more than a handful of times.
 
in the sense that shouldn't enable be refactored to use *more* of pyface?

No, Enable uses TraitsUI to provide ComponentEditor, SvgButtonEditor and code to support colors and fonts. There isn't much in Pyface that Enable would ever want to explicitly use. If you grep through the code, you'll see it 2 direct uses of pyface- one for a timer object to determine when to pop up the hover window, and the other for a menu.


Gotcha.  Ok.  Thanks for clarifying. 

Lost in all of this I think was Ilan's discussion of why we are keeping the api.py files as well.

'from traits.api import ...' is still far better than 'from enthought.traits.api import ...' 

Be Well
Anthony
 

Bryce

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Martin Chilvers
In reply to this post by Ilan Schnell
G'day,

On 19/04/2011 17:47, Ilan Schnell wrote:
> Eric pointed out that the reason for having the api.py files, and
> not defining the api in __init__.py, is to allow users to only import
> a single submodule, without the api being executed (and thereby
> importing all modules).

Yep - that was one of the big benefits of the .api files - it is really
nice to be able to import submodules without causing any other imports
to happen - I am always suspicious when __init__.py files are *not* empty!

For me, the other benefit of the .api files is that they tell me as a
client of a package what I am supposed to use, and as a developer of a
package it defines what I consider my public API and therefore have to
manage in terms of versioning etc. It doesn't mean clients can't reach
in and re-use something 'non-public' of course, but if the do they
should do so knowing that the api is more liable to change without warning!

There can be performance problems of course if the .api file imports a
lot of code, but it is probably reasonable to use the .api file to find
what you want and then import it directly (although this would mean that
modules in the package should *not* import local modules via the .api
file). Again, this is slightly more fragile since the package developer
might change the location of a symbol, but might be a nice compromise...

Martin
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Ilan Schnell
Thanks you for the explanation Martin.
We are keeping the api.py files.  Do you agree
that joining envisagecore and envisageplugins
into a single envisage project (which would have
the plugins available under envisage.plugins) is
a good idea?

- Ilan

On Sat, Apr 23, 2011 at 3:50 AM, Martin Chilvers
<[hidden email]> wrote:

> G'day,
>
> On 19/04/2011 17:47, Ilan Schnell wrote:
>> Eric pointed out that the reason for having the api.py files, and
>> not defining the api in __init__.py, is to allow users to only import
>> a single submodule, without the api being executed (and thereby
>> importing all modules).
>
> Yep - that was one of the big benefits of the .api files - it is really
> nice to be able to import submodules without causing any other imports
> to happen - I am always suspicious when __init__.py files are *not* empty!
>
> For me, the other benefit of the .api files is that they tell me as a
> client of a package what I am supposed to use, and as a developer of a
> package it defines what I consider my public API and therefore have to
> manage in terms of versioning etc. It doesn't mean clients can't reach
> in and re-use something 'non-public' of course, but if the do they
> should do so knowing that the api is more liable to change without warning!
>
> There can be performance problems of course if the .api file imports a
> lot of code, but it is probably reasonable to use the .api file to find
> what you want and then import it directly (although this would mean that
> modules in the package should *not* import local modules via the .api
> file). Again, this is slightly more fragile since the package developer
> might change the location of a symbol, but might be a nice compromise...
>
> Martin
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ETS Sprints Report

Martin Chilvers
Hi Ilan,

On 23/04/2011 14:16, Ilan Schnell wrote:
> Thanks you for the explanation Martin.
> We are keeping the api.py files.  Do you agree
> that joining envisagecore and envisageplugins
> into a single envisage project (which would have
> the plugins available under envisage.plugins) is
> a good idea?

That's a tricky one - it seems like the plugins should be in other
projects, possibly close to the code that they 'lift' into the envisage
infratructure i.e. the workbench plugin smells like it should live with
the pyface workbench since that is what it makes available to envisage
applications. I know that seems weird since pyface does not require
envisage, but putting all plugins in one place seems odd too. Having
said that, I'm not against putting the two projects togther until we
come up with a better idea!

It would be nice if we could tag bits of code (in Web 0.2, errr, 2.0
style) and then browse the codebase using those tags instead of
arbitrary file-system layouts which are just one 'view'...

Martin
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev