On 2/11/07, Nicolas Grilly <[EMAIL PROTECTED]> wrote:
> When you are working on matplotlib, after a checkout from the SVN
> repository, which method do you use to compile extensions without
> re-building and re-installing everything each time?
I rebuild and reinstall each time. Since only the ch
"Nicolas Grilly" <[EMAIL PROTECTED]> writes:
> When you are working on matplotlib, after a checkout from the SVN
> repository, which method do you use to compile extensions without
> re-building and re-installing everything each time?
I use "python setupegg.py develop", which I think does the sam
Jouni K. Seppänen wrote:
> "Nicolas Grilly" <[EMAIL PROTECTED]> writes:
>
>
>> When you are working on matplotlib, after a checkout from the SVN
>> repository, which method do you use to compile extensions without
>> re-building and re-installing everything each time?
>>
>
> I use "python s
John Hunter wrote:
> I am inclined to consider ripping out the __init__ stuff into a
> "config" module or something like that.
+1
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done qui
On 2/12/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> IMO, the way to fix it is to move all the data into
> lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> that setup.py does would be unnecessary and using setuptools' develop
> mode would work out-of-the-box. I'd be happy
On 2/12/07, John Hunter <[EMAIL PROTECTED]> wrote:
> On 2/12/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> > IMO, the way to fix it is to move all the data into
> > lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> > that setup.py does would be unnecessary and using setupto
On 2/12/07, Charlie Moad <[EMAIL PROTECTED]> wrote:
> You're changing positions on me now, John! ;)
It's better that way -- that way I can be right both times :-) Or is
it wrong both times? hmmm...
> I asked about moving everything into the module, but you didn't want
> to mix the fonts/image
On 2/12/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> IMO, the way to fix it is to move all the data into
> lib/matplotlib/mpl-data to start with. If we did that, all the shuffling
> that setup.py does would be unnecessary and using setuptools' develop
> mode would work out-of-the-box. I'd be happy
John Hunter wrote:
> On 2/12/07, Charlie Moad <[EMAIL PROTECTED]> wrote:
>
>> You're changing positions on me now, John! ;)
>
> It's better that way -- that way I can be right both times :-) Or is
> it wrong both times? hmmm...
>
>> I asked about moving everything into the module, but you didn't
On 2/12/07, John Hunter <[EMAIL PROTECTED]> wrote:
> OK, I see, so the problem was we had to flatten everything and mix all
> these datatypes together? eggs can't handle the existing directory
> structure in the mpl-data? It would clearly be better if it could,
> because dumping all the data file
> Well, another option is to maintain a sub-directory structure when
> creating mpl-data in the source package. The downside is that this will
> introduce code changes all over the code -- for example, code that
> previously asked for "os.path.join( mpl.get_data_dir(), 'blah.glade' )"
> would have
Charlie Moad wrote:
>> Well, another option is to maintain a sub-directory structure when
>> creating mpl-data in the source package. The downside is that this will
>> introduce code changes all over the code -- for example, code that
>> previously asked for "os.path.join( mpl.get_data_dir(), 'blah
Looking in detail at the contents of the mpl-directory, I notice that
A) the gui/ subdirectory off the main MPL source direcotry (the one with
setup.py) does not exist in SVN
B) the file "lineprops.glade" referenced by
backends/backend_gtk/DialogLineprops.py
does not exist in SVN
Is it safe to
> Although my understanding of setup* is minimal, I agree; I think that
> keeping some organization in the data will be helpful. It looks like
> get_data_path() is not called in many places, so if that is essentially
> what has to be fixed, it should not be very difficult. It might be
> facilitat
Charlie Moad wrote:
>> Although my understanding of setup* is minimal, I agree; I think that
>> keeping some organization in the data will be helpful. It looks like
>> get_data_path() is not called in many places, so if that is essentially
>> what has to be fixed, it should not be very difficult.
Thanks for tackling this.
On 2/12/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> Charlie Moad wrote:
> >> Although my understanding of setup* is minimal, I agree; I think that
> >> keeping some organization in the data will be helpful. It looks like
> >> get_data_path() is not called in many place
Looking through colors.py, I noticed that most of the grey cnames use
the spelling 'gray' (the US standard I think), although 'lightgrey'
shows up as a valid name, while 'lightgray' does not. After looking
around the web a bit for what the correct html names are, I found most
sites display 'gra
On 2/12/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> So, I sent the patch file to John, who'll hopefully commit it if he
> approves. To paraphrase Robert Kern, "Working code ends all arguments".
> So, since this was the nested way, and the biggest reason against it was
> that it require code chan
On 2/12/07, Martin Spacek <[EMAIL PROTECTED]> wrote:
> Looking through colors.py, I noticed that most of the grey cnames use
> the spelling 'gray' (the US standard I think), although 'lightgrey'
> shows up as a valid name, while 'lightgray' does not. After looking
> around the web a bit for what th
Great, thanks for checking that in.
It looks like images/*.png didn't make it in.
John Hunter wrote:
> On 2/12/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
>
>
>> So, I sent the patch file to John, who'll hopefully commit it if he
>> approves. To paraphrase Robert Kern, "Working code ends all a
Andrew Straw wrote:
> Great, thanks for checking that in.
>
> It looks like images/*.png didn't make it in.
>
And, grr, I can't put them in, either:
$ svn commit -m "added .png files that didn't make it into new mpl-data
location" images
Adding (bin) images/back.png
svn: Commit failed (detai
21 matches
Mail list logo
