matplotlib-devel Mailing List for matplotlib

On 01/07/2013 12:38 PM, Eric Firing wrote:
> On 2013年01月07日 7:29 AM, Michael Droettboom wrote:
>> I, also, am not too much up on the details --- but I think if it's
>> possible for "make install" to just call "python setup.py install" under
>> the hood, I'd have no objections.
> I think I would even object to that. What would be the point of it?
> What problem would it solve?
>
Very little point, admittedly. But I still encounter sysadmins who 
insist on "./configure; make; make install" to work sometimes.
Mike

On Po, 2013年01月07日 at 07:38 -1000, Eric Firing wrote:
> On 2013年01月07日 7:29 AM, Michael Droettboom wrote:
> > I, also, am not too much up on the details --- but I think if it's
> > possible for "make install" to just call "python setup.py install" under
> > the hood, I'd have no objections.
> 
> I think I would even object to that. What would be the point of it? 
> What problem would it solve?
> 
> Eric
There is one thing autotools are good at: Very easy cross-compilation
for end-users and pleasant handling of the C/C++ stuff (conditional
compilation, custom flags specified on command-line, lots of checks you
can perform before compilation, integrated testing framework etc.)
The only pitfall is that writing autotools stuff without knowing best
practices or without having full understanding of what you are doing is
going to result in endless bugreports you won't know how to solve.
If matplotlib relies heavily on C libraries, it might be beneficial,
otherwise it is probably not worth the effort for Python projects.
Matej

On 2013年01月07日 7:29 AM, Michael Droettboom wrote:
> I, also, am not too much up on the details --- but I think if it's
> possible for "make install" to just call "python setup.py install" under
> the hood, I'd have no objections.
I think I would even object to that. What would be the point of it? 
What problem would it solve?
Eric

On 01/07/2013 12:24 PM, Benjamin Root wrote:
>
>
> On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl... 
> <mailto:th...@kl...>> wrote:
>
> On 7 January 2013 16:57, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
> I was just reading some comments from Richard Stallman on ./
> when I noticed that he pointed out a useful autoconf feature
> that was added somewhat recently. Essentially, this feature
> would allow one to do a build/install of a python module using
> the "./configure; make install" approach, if one chooses. 
> Maybe it should be something to consider adding to our build
> system?
>
>
> My 2 cents: I took over the maintenance of a Python project built
> by autotools. The build system felt more complex than the actual
> application - a fantastic world of .am files generating .in files
> generating Makefiles, which themselves were packed with
> abstractions. I had little idea how to change anything in the
> build process, and before long I ripped it out in favour of
> setup.py, despite all distutils' flaws.
>
> I'm sure that's more a question of my experience than of
> autotools, but I'd think twice before adding it to a project.
>
> Best wishes,
> Thomas
>
>
> That's a very good point. I certainly don't want to add significant 
> complexity to our build system. We certainly have enough of it 
> as-is. I was hoping that there was a way to complement our setup.py 
> approach. In other words, "python setup.py install" would be our 
> primary means of build/install, while allowing for "make install" as 
> an alternative. I have yet to actually look into how this current 
> autoconf feature would work and if that is even possible.
I, also, am not too much up on the details --- but I think if it's 
possible for "make install" to just call "python setup.py install" under 
the hood, I'd have no objections. What I'd be wary of would be 
maintaining multiple install scripts. It's hard enough keeping one up 
to date with all of the various platforms and configurations we 
support. I'd be happy to replace that one with something that's clearly 
superior, however, but distutils, bad as it is, seems to be "good enough".
Mike

On 2013年01月07日 7:24 AM, Benjamin Root wrote:
>
>
> On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl...
> <mailto:th...@kl...>> wrote:
>
> On 7 January 2013 16:57, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
> I was just reading some comments from Richard Stallman on ./
> when I noticed that he pointed out a useful autoconf feature
> that was added somewhat recently. Essentially, this feature
> would allow one to do a build/install of a python module using
> the "./configure; make install" approach, if one chooses. Maybe
> it should be something to consider adding to our build system?
>
>
> My 2 cents: I took over the maintenance of a Python project built by
> autotools. The build system felt more complex than the actual
> application - a fantastic world of .am files generating .in files
> generating Makefiles, which themselves were packed with
> abstractions. I had little idea how to change anything in the build
> process, and before long I ripped it out in favour of setup.py,
> despite all distutils' flaws.
>
> I'm sure that's more a question of my experience than of autotools,
> but I'd think twice before adding it to a project.
>
> Best wishes,
> Thomas
>
>
> That's a very good point. I certainly don't want to add significant
> complexity to our build system. We certainly have enough of it as-is.
> I was hoping that there was a way to complement our setup.py approach.
> In other words, "python setup.py install" would be our primary means of
> build/install, while allowing for "make install" as an alternative. I
> have yet to actually look into how this current autoconf feature would
> work and if that is even possible.
Ben,
What specific problem with our present system would you be trying to 
solve? I'm with Thomas on this--and there's a reason why people keep 
trying to develop new build systems, like cmake, scons, and waf, instead 
of being content with autotools.
Eric
>
> Ben Root

On 01/07/2013 11:05 AM, Nelle Varoquaux wrote:
> On 7 January 2013 16:38, Michael Droettboom <md...@st...> wrote:
>> I know there's a lot of code in the wild that treats cbook as public and
>> would probably be affected by it going away. However, there hasn't been
>> much care taken within that module as to what we want to support
>> publicly and what would be better left as private. Many things in it,
>> of course, are imported to the top-level of the matplotlib package, and
>> those are quite strongly public, I would say, but we probably have to do
>> these things on a case-by-case basis. I think the best approach is to
>> probably deprecate now and remove later -- though there may be some
>> things in there that we want to keep even if they aren't used internally
>> (but let's add some tests in the latter case). Do you have a complete
>> list of everything in cbook that isn't used by matplotlib itself?
> This is a list I quickly built: I have no certainty that it is correct
> nor complete:
>
> book's unused functions and classes in matplotlib:
>
> unmasked_index_ranges
> tostr (note that there is a method called tostr in mlab)
> todatetime
> todate
> tofloat
> toint
> _BoundMethodProxy
> TimeOut
> Idler
> Scheduler (is used by TimeOut and Idler)
> uniquer
> Sorter
> Xlator
> soundex
> Null
> dict_delall
> RingBuffer
> wrap (unsure)
> pieces
> alltrue
> allpairs
> finddir
> reverse_dict
> MemoryMonitor
> unmasked_index_ranges
>
> functions that are redefined elsewhere:
> is_math_text (in the text module)
>
> I can have a closer look and deprecate things that aren't used
> anywhere and don't seem very useful to anyone.
That seems like a reasonable approach.
One way to handle this might be to
a) create a new module "_cbook.py" for internal use.
b) move everything used internally into there
c) in cbook.py, put "from _cbook import *" and include all of these 
other functions in there
d) emit a MatplotlibDeprecationWarning at the top level of cbook.py so 
there's a deprecation warning about the entire module.
I'm not sure this is the best approach, but it's an easy way to 
deprecate a lot of things at once. Comments from other are appreciated.
Cheers,
Mike
>
> Thanks,
> N
>
>> Mike
>>
>>
>> On 01/07/2013 10:24 AM, Nelle Varoquaux wrote:
>>> Hello everyone,
>>>
>>> I was recently looking at the cbook module, and I was wondering
>>> whether this module was public or not. I think there are several
>>> unused method in it, such as ``unmasked_index_ranges``. If this isn't
>>> public, it may be worth cleaning the module a bit and removing the
>>> unused method.
>>>
>>> Cheers,
>>> Nelle
>>>
>>> ------------------------------------------------------------------------------
>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
>>> http://p.sf.net/sfu/learnmore_122412
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122412
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl...>wrote:
> On 7 January 2013 16:57, Benjamin Root <ben...@ou...> wrote:
>
>> I was just reading some comments from Richard Stallman on ./ when I
>> noticed that he pointed out a useful autoconf feature that was added
>> somewhat recently. Essentially, this feature would allow one to do a
>> build/install of a python module using the "./configure; make install"
>> approach, if one chooses. Maybe it should be something to consider adding
>> to our build system?
>
>
> My 2 cents: I took over the maintenance of a Python project built by
> autotools. The build system felt more complex than the actual application -
> a fantastic world of .am files generating .in files generating Makefiles,
> which themselves were packed with abstractions. I had little idea how to
> change anything in the build process, and before long I ripped it out in
> favour of setup.py, despite all distutils' flaws.
>
> I'm sure that's more a question of my experience than of autotools, but
> I'd think twice before adding it to a project.
>
> Best wishes,
> Thomas
>
>
That's a very good point. I certainly don't want to add significant
complexity to our build system. We certainly have enough of it as-is. I
was hoping that there was a way to complement our setup.py approach. In
other words, "python setup.py install" would be our primary means of
build/install, while allowing for "make install" as an alternative. I have
yet to actually look into how this current autoconf feature would work and
if that is even possible.
Ben Root

On 7 January 2013 16:57, Benjamin Root <ben...@ou...> wrote:
> I was just reading some comments from Richard Stallman on ./ when I
> noticed that he pointed out a useful autoconf feature that was added
> somewhat recently. Essentially, this feature would allow one to do a
> build/install of a python module using the "./configure; make install"
> approach, if one chooses. Maybe it should be something to consider adding
> to our build system?
My 2 cents: I took over the maintenance of a Python project built by
autotools. The build system felt more complex than the actual application -
a fantastic world of .am files generating .in files generating Makefiles,
which themselves were packed with abstractions. I had little idea how to
change anything in the build process, and before long I ripped it out in
favour of setup.py, despite all distutils' flaws.
I'm sure that's more a question of my experience than of autotools, but I'd
think twice before adding it to a project.
Best wishes,
Thomas

I was just reading some comments from Richard Stallman on ./ when I noticed
that he pointed out a useful autoconf feature that was added somewhat
recently. Essentially, this feature would allow one to do a build/install
of a python module using the "./configure; make install" approach, if one
chooses. Maybe it should be something to consider adding to our build
system?
http://www.gnu.org/software/automake/manual/html_node/Python.html
Cheers!
Ben Root

On 7 January 2013 16:38, Michael Droettboom <md...@st...> wrote:
> I know there's a lot of code in the wild that treats cbook as public and
> would probably be affected by it going away. However, there hasn't been
> much care taken within that module as to what we want to support
> publicly and what would be better left as private. Many things in it,
> of course, are imported to the top-level of the matplotlib package, and
> those are quite strongly public, I would say, but we probably have to do
> these things on a case-by-case basis. I think the best approach is to
> probably deprecate now and remove later -- though there may be some
> things in there that we want to keep even if they aren't used internally
> (but let's add some tests in the latter case). Do you have a complete
> list of everything in cbook that isn't used by matplotlib itself?
This is a list I quickly built: I have no certainty that it is correct
nor complete:
book's unused functions and classes in matplotlib:
unmasked_index_ranges
tostr (note that there is a method called tostr in mlab)
todatetime
todate
tofloat
toint
_BoundMethodProxy
TimeOut
Idler
Scheduler (is used by TimeOut and Idler)
uniquer
Sorter
Xlator
soundex
Null
dict_delall
RingBuffer
wrap (unsure)
pieces
alltrue
allpairs
finddir
reverse_dict
MemoryMonitor
unmasked_index_ranges
functions that are redefined elsewhere:
is_math_text (in the text module)
I can have a closer look and deprecate things that aren't used
anywhere and don't seem very useful to anyone.
Thanks,
N
>
> Mike
>
>
> On 01/07/2013 10:24 AM, Nelle Varoquaux wrote:
>> Hello everyone,
>>
>> I was recently looking at the cbook module, and I was wondering
>> whether this module was public or not. I think there are several
>> unused method in it, such as ``unmasked_index_ranges``. If this isn't
>> public, it may be worth cleaning the module a bit and removing the
>> unused method.
>>
>> Cheers,
>> Nelle
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122412
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I know there's a lot of code in the wild that treats cbook as public and 
would probably be affected by it going away. However, there hasn't been 
much care taken within that module as to what we want to support 
publicly and what would be better left as private. Many things in it, 
of course, are imported to the top-level of the matplotlib package, and 
those are quite strongly public, I would say, but we probably have to do 
these things on a case-by-case basis. I think the best approach is to 
probably deprecate now and remove later -- though there may be some 
things in there that we want to keep even if they aren't used internally 
(but let's add some tests in the latter case). Do you have a complete 
list of everything in cbook that isn't used by matplotlib itself?
Mike
On 01/07/2013 10:24 AM, Nelle Varoquaux wrote:
> Hello everyone,
>
> I was recently looking at the cbook module, and I was wondering
> whether this module was public or not. I think there are several
> unused method in it, such as ``unmasked_index_ranges``. If this isn't
> public, it may be worth cleaning the module a bit and removing the
> unused method.
>
> Cheers,
> Nelle
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Yes, it is public, but it is geared for internal use.

Hello everyone,
I was recently looking at the cbook module, and I was wondering
whether this module was public or not. I think there are several
unused method in it, such as ``unmasked_index_ranges``. If this isn't
public, it may be worth cleaning the module a bit and removing the
unused method.
Cheers,
Nelle