Re: Problems with new SVN repo setup and egg

>>>>> "Andres" == Andres Gonzalez-Mancera
<gonzalezmancera+scipy@...> writes:

    >> FWIW, I just tried it on my Intel Mac and got everything. I'm
    >> not sure why Andres didn't.

    Andres> I updated my setuptools and it now worked!!! Now back to

Great!  Could you *please* just mention the version of setuptools you
had and which one you upgraded to and add it to the end of this page:

 https://svn.enthought.com/enthought/wiki/InstallWithEggs

Thank you!

    Andres> my other question, what is the recommended way to 'study'
    Andres> the code? What would the equivalent to build-inplace be?

I guess Dave has answered this in considerable detail.

regards,
prabhu

Re: Problems with new SVN repo setup and egg

>>>>> "Andres" == Andres Gonzalez-Mancera
<gonzalezmancera+scipy@...> writes:
    Andres> accessible and so were the examples. I also like that I
    Andres> could keep my code very up-to-date by 'svn up' and
    Andres> rebuilding inplace. This way I was able to report a few
    Andres> bugs I encountered and had access to the revision once
    Andres> they were fixed very quickly. With the new method
    Andres> involving eggs is there an equivalent way of having a
    Andres> 'developing' copy to learn and work from without having to
    Andres> install to the site-package? If so, is this documented
    Andres> somewhere?

You can install the packages inside your own home directory if you
think that better.  On the Mac I use this:

$ less ~/.pydistutils.cfg 
[install]
install_lib = ~/Library/Python/$py_version_short/site-packages
install_scripts = ~/usr/bin

On Linux I have this:
$ less ~/.pydistutils.cfg 
[install]
install_lib = ~/usr/lib/python
install_scripts = ~/usr/bin

While having the SVN tree in one place and using inplace is
convenient, it really makes it hard for every package maintainer to
keep in sync with everyone else.  The clean package seperation has its
advantages.  easy_install is easy enough to use that managing the many

Re: Problems with new SVN repo setup and egg

>>>>> "Dave" == Dave Peterson <dpeterson@...> writes:

    Dave> BTW, Prabhu's eggs are on our site here:
    Dave> http://code.enthought.com/enstaller/platform/macosx

    Dave> I'm bringing this up because he indicated his site was a
    Dave> temporary location so we might as well get used to using the
    Dave> above. 

Well, I can make it not-too-temporary but I was afraid that it might
not be fast enough for everyone.  Plus, it is convenient to keep all
the eggs in one basket.  You very likely have less downtime/network
related issues than we have here.  Ideally I'd like to use that url as
a place to put things up for download which can then be absorbed into
the enthought repo if the packages are OK and you folks are OK with
it.

I will keep a set of eggs handy in the campus network here though.

cheers,
prabhu

Re: Problems with new SVN repo setup and egg

On Fri, Jun 01, 2007 at 11:08:48AM +0530, Prabhu Ramachandran wrote:
> You can install the packages inside your own home directory if you
> think that better.  On the Mac I use this:

> $ less ~/.pydistutils.cfg 
> [install]
> install_lib = ~/Library/Python/$py_version_short/site-packages
> install_scripts = ~/usr/bin

> On Linux I have this:
> $ less ~/.pydistutils.cfg 
> [install]
> install_lib = ~/usr/lib/python
> install_scripts = ~/usr/bin

I used a symbolic link from /home/varoquau/Programs/enthought to
/usr/local/lib/python2.5/site-packages/enthought with the previous svn
layout. I do not have a workflow yet with the current.

The good thing about the symbolic link is that it is transparent to
Python. The bad thing is that to mix ETS versions you need to move
symbolic links around.

Gaël

Re: annotations in chaco2

On May 30, 2007, at 1:50 AM, Eli Ateljevich wrote:

>> Check out datalabel.py and data_labels.py demo in the examples.  The
>> arrowhead drawing code isn't in there yet, but it draws a marker on
>> the data point now.
>
> Thanks, Peter, it works well. Is the trend line something that can  
> be done?

What exactly did you want the trend line to do?

BTW I've added arrowhead rendering to the DataLabel now, as well as a  
tool that allows you to drag the label around.

> In looking this up, I noticed there is a multiaxis example in the
> repository. I am interested in this functionality. I have been trying
> to use the PlotData-driven class Plot, because I recall your once
> saying that plot_factory and create_line_plot would eventually be
> deprecated. Do I have this wrong?

No, you are right.  I would like to get rid of the stuff in  
plot_factory.py at some point.

> It seems like multiaxis is not
> compatible with the assumptions of Plot -- it requires an
> OverlayContainer with two LinePlots.

Well, to be precise, a Plot is just a subclass of OverlayContainer,  
but it imposes the restriction that all plots created on it using its  
various plot()/img_plot()/etc. methods all share the same index and  

preferred way to calculate text size in kiva?

I need to calculate the size of some text I am going to display, but I 
am not in a draw method, so I don't have a gc handy to ask.  So, I 
created one (using GraphicsContext from kiva.backend_image):

        # Text width calculation.
        gc = GraphicsContext((1,1))
        gc.set_font(self.style.title_font)
        x, y, tx, ty = gc.get_text_extent(self.display_label)

I seem to remember Robert K. changing things to get kiva working nicely 
on the mac so that this is no longer the preferred method.  What should 
I be using?

thanks,
eric

Re: preferred way to calculate text size in kiva?

On Jun 1, 2007, at 4:03 AM, eric jones wrote:
> I need to calculate the size of some text I am going to display, but I
> am not in a draw method, so I don't have a gc handy to ask.  So, I
> created one (using GraphicsContext from kiva.backend_image):
> I seem to remember Robert K. changing things to get kiva working  
> nicely
> on the mac so that this is no longer the preferred method.  What  
> should
> I be using?

from enthought.kiva import font_metrics_provider

# Instead of doing gc = GraphicsContext((1,1)), do this:
metrics = font_metrics_provider()
metrics.set_font(my_font)
metrics.get_text_extend(my_text)

-Peter

Installation error on WinXP ?

Eggs and I just don't get along.   (Please reassure me that eggs are
an improvment  :)  )

Trying to install on WinXP / python 2.5

Here's what I typed:

C:\Documents and Settings\Admin\My Documents\My Downloads>python ./run_enstaller
.py -f http://code.enthought.com/enstaller/eggs/py25

Here's what I got:

[... lots of stuff, not shown...]
Downloading: http://code.enthought.com/enstaller/eggs/py25/enthought.util-1.1.0_
r11717-py2.5.egg
enthought.util-1.1.0_r11717-py2.| *****************************| 00h:00m:03.38s
easy_install> Processing enthought.util-1.1.0_r11717-py2.5.egg

An error was encountered while bootstrapping Enstaller!

Internal Error: <type 'exceptions.ImportError'>: No module named resource.resour
ce_path

Please submit the following postmortem file to the authors:
C:\Documents and Settings\Admin\My Documents\My Downloads\ENSTALLER_POSTMORTEM.t
xt

-gary

[traits] Enum bug (?)

Hi,

Can someone try the two examples attached please,
and give some explanation ?

Cheers,

--

-- 
http://scipy.org/FredericPetit

_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev

Re: Enthought-dev Digest, Vol 34, Issue 1

> Studying and building-inplace is now done on a per component basis.
> Each component has a tree like:
>
>     enthought.<component name>/
>        doc/                (if any provided)
>        examples/        (if any provided)
>        enthought/
>           __init__.py
>           <component name>/
>              __init__.py
>              ....
>        setup.py
>
> So you'd check out from SVN (or, after we publish them, download a
> source tarball) the specific components you're interested in, and browse
> its source there.   If you want to play around with that source (meaning
> modify code and see the effects), do a 'python setup.py develop' at the
> top level of that component's directory.  This will point your Python
> environment at your checkout version instead of the previously installed
> egg and let you make changes to .py files without needing a new
> egg-building step.
>
>
> BTW,   if you really want to stay on the old version of the trunk for
> awhile, say until we get all this new stuff tested and working, you
> could still have a checkout of /branches/old/trunk from the repo (note
> that soon this will be something like /branches.old/trunk)   This is the
> old structure before the refactor.
>
>