matplotlib-devel Mailing List for matplotlib

On Sat, Mar 5, 2011 at 10:34, Eric Firing <ef...@ha...> wrote:

> Newer versions of the libraries can also be used, although this is not
> critical.  v1.0.x still needs the 1.2 series of libpng, but master can
> now handle
>
> ZLIBVERSION=1.2.5
> PNGVERSION=1.5.1
> FREETYPEVERSION=2.4.4
>

We have to make sure to check/update the urls to the new versions of these
dependencies. I'm unsure whether having variables for the versions makes
sense when the urls change over time (e.g.: the libpng currently in use in
make.osx was moved into the older-releases folder of the libpng repo,
prompting the need for this pull request in the first place).

-- Fernando

I tested your changes (up to mpl_install_std) and merged the pull request.
Upon solving the binaries issue we could probably close this pull request.
Or we could open an issue for that particular matter.

-- Fernando


On Sat, Mar 5, 2011 at 02:03, Jouni K. Seppänen <jk...@ik...> wrote:

> Jouni K. Seppänen <jk...@ik...> writes:
>
> > Fernando Garcia Bermudez <fg...@ee...> writes:
> >
> >> Fine by me as well. Maybe modify the documentation to point to
> >> mpl_install_std. How should we proceed?
> >
> > I'll make some other cleanups and create some commits that you can
> > include in your pull request.
>
> I did this now and created a pull request for you, so if you pull it
> into your branch, it should update your pull request. I realized it's
> unnecessary to have all those shell commands to export the variables,
> since make can export them for us.
>
> I tried out the other targets, but I couldn't get "binaries" to
> work. The bdist_mpkg plugin complains something about a lacking 64-bit
> wxpython. Could someone who has previously been able to create the
> installer try it on my make.osx branch? (That is,
>
>  git add remote jkseppan git://github.com/jkseppan/matplotlib.git
>  git fetch jkseppan
>  git checkout jkseppan/make.osx
>  make -f make.osx clean deps mpl_build binaries PYVERSION=2.6 PREFIX=...)
>
> This change will likely not merge cleanly into master; if people agree
> to merge this into the maintenance branch, I can do the merge into
> master.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 03/05/2011 12:03 AM, Jouni K. Seppänen wrote:
> Jouni K. Seppänen<jk...@ik...>  writes:
>
>> Fernando Garcia Bermudez<fg...@ee...>  writes:
>>
>>> Fine by me as well. Maybe modify the documentation to point to
>>> mpl_install_std. How should we proceed?
>>
>> I'll make some other cleanups and create some commits that you can
>> include in your pull request.
>
> I did this now and created a pull request for you, so if you pull it
> into your branch, it should update your pull request. I realized it's
> unnecessary to have all those shell commands to export the variables,
> since make can export them for us.
>
> I tried out the other targets, but I couldn't get "binaries" to
> work. The bdist_mpkg plugin complains something about a lacking 64-bit
> wxpython. Could someone who has previously been able to create the
> installer try it on my make.osx branch? (That is,
>
>    git add remote jkseppan git://github.com/jkseppan/matplotlib.git
>    git fetch jkseppan
>    git checkout jkseppan/make.osx
>    make -f make.osx clean deps mpl_build binaries PYVERSION=2.6 PREFIX=...)
>
> This change will likely not merge cleanly into master; if people agree
> to merge this into the maintenance branch, I can do the merge into
> master.
>
Jouni,

While in the middle of overhauling make.osx, I think it makes sense to 
go ahead and fix the ARCH_FLAGS variable, and then use it throughout in 
place of the hardwired ARCH_FLAGS.  That will make it easier to use the 
makefile on a range of OS X and Xcode versions.  It is also simply a 
cleaner design.

Newer versions of the libraries can also be used, although this is not 
critical.  v1.0.x still needs the 1.2 series of libpng, but master can 
now handle

ZLIBVERSION=1.2.5
PNGVERSION=1.5.1
FREETYPEVERSION=2.4.4


Eric

Jouni K. Seppänen <jk...@ik...> writes:

> Fernando Garcia Bermudez <fg...@ee...> writes:
>
>> Fine by me as well. Maybe modify the documentation to point to
>> mpl_install_std. How should we proceed?
>
> I'll make some other cleanups and create some commits that you can
> include in your pull request.

I did this now and created a pull request for you, so if you pull it
into your branch, it should update your pull request. I realized it's
unnecessary to have all those shell commands to export the variables,
since make can export them for us.

I tried out the other targets, but I couldn't get "binaries" to
work. The bdist_mpkg plugin complains something about a lacking 64-bit
wxpython. Could someone who has previously been able to create the
installer try it on my make.osx branch? (That is, 

  git add remote jkseppan git://github.com/jkseppan/matplotlib.git
  git fetch jkseppan
  git checkout jkseppan/make.osx
  make -f make.osx clean deps mpl_build binaries PYVERSION=2.6 PREFIX=...)

This change will likely not merge cleanly into master; if people agree
to merge this into the maintenance branch, I can do the merge into
master.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Fernando Garcia Bermudez <fg...@ee...> writes:

> Fine by me as well. Maybe modify the documentation to point to
> mpl_install_std. How should we proceed?

I'll make some other cleanups and create some commits that you can
include in your pull request.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Fine by me as well. Maybe modify the documentation to point to
mpl_install_std. How should we proceed?

-- Fernando


On Fri, Mar 4, 2011 at 23:55, Eric Firing <ef...@ha...> wrote:

> On 03/04/2011 09:09 PM, Jouni K. Seppänen wrote:
> > Eric Firing<ef...@ha...>  writes:
> >
> >> What is the rationale for removing the --prefix argument?  It doesn't
> >> prevent one from installing in the standard location.
> >
> > The $PREFIX variables is used by make.osx for two different purposes:
> > (1) the dependencies are installed under $PREFIX and the extensions are
> > compiled to use them from there, in order to avoid version mismatches
> > with libraries in /usr, /opt, etc.; (2) the "setup.py install" command
> > is given --prefix $PREFIX as an argument so that matplotlib gets
> > installed in a non-standard location.
> >
> > I like just (1), so to install matplotlib I do "make -n mpl_install"
> > and edit the command to remove the prefix. Or, actually, edit it to be
> > "setupegg.py develop". The Makefile sets a bunch of environment
> > variables that are needed for the compilation to succeed with the
> > downloaded dependencies.
> >
> > How about putting the environment assignments in just one place and
> > creating multiple installation targets, maybe like this:
> >
> > ------------------------------------------------------------------------
> > run_cmd:
> >          export PKG_CONFIG_PATH=${PKG_CONFIG_PATH} \
> >          (etc) \
> >          ${PYTHON} ${CMD}
> >
> > mpl_build:
> >          run_cmd CMD="setup.py build"
> >
> > mpl_install:
> >          run_cmd CMD="setup.py install --prefix=${PREFIX}"
> >
> > mpl_install_std:
> >          run_cmd CMD="setup.py install"
> >
> > mpl_develop:
> >          run_cmd CMD="setupegg.py develop"
> > ------------------------------------------------------------------------
> >
>
> That looks to me like a good solution.
>
> Eric
>
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 03/04/2011 09:09 PM, Jouni K. Seppänen wrote:
> Eric Firing<ef...@ha...>  writes:
>
>> What is the rationale for removing the --prefix argument?  It doesn't
>> prevent one from installing in the standard location.
>
> The $PREFIX variables is used by make.osx for two different purposes:
> (1) the dependencies are installed under $PREFIX and the extensions are
> compiled to use them from there, in order to avoid version mismatches
> with libraries in /usr, /opt, etc.; (2) the "setup.py install" command
> is given --prefix $PREFIX as an argument so that matplotlib gets
> installed in a non-standard location.
>
> I like just (1), so to install matplotlib I do "make -n mpl_install"
> and edit the command to remove the prefix. Or, actually, edit it to be
> "setupegg.py develop". The Makefile sets a bunch of environment
> variables that are needed for the compilation to succeed with the
> downloaded dependencies.
>
> How about putting the environment assignments in just one place and
> creating multiple installation targets, maybe like this:
>
> ------------------------------------------------------------------------
> run_cmd:
>          export PKG_CONFIG_PATH=${PKG_CONFIG_PATH} \
>          (etc) \
>          ${PYTHON} ${CMD}
>
> mpl_build:
>          run_cmd CMD="setup.py build"
>
> mpl_install:
>          run_cmd CMD="setup.py install --prefix=${PREFIX}"
>
> mpl_install_std:
>          run_cmd CMD="setup.py install"
>
> mpl_develop:
>          run_cmd CMD="setupegg.py develop"
> ------------------------------------------------------------------------
>

That looks to me like a good solution.

Eric

Eric Firing <ef...@ha...> writes:

> What is the rationale for removing the --prefix argument?  It doesn't 
> prevent one from installing in the standard location.

The $PREFIX variables is used by make.osx for two different purposes: 
(1) the dependencies are installed under $PREFIX and the extensions are
compiled to use them from there, in order to avoid version mismatches
with libraries in /usr, /opt, etc.; (2) the "setup.py install" command
is given --prefix $PREFIX as an argument so that matplotlib gets
installed in a non-standard location.

I like just (1), so to install matplotlib I do "make -n mpl_install"
and edit the command to remove the prefix. Or, actually, edit it to be
"setupegg.py develop". The Makefile sets a bunch of environment
variables that are needed for the compilation to succeed with the
downloaded dependencies.

How about putting the environment assignments in just one place and
creating multiple installation targets, maybe like this:

------------------------------------------------------------------------
run_cmd:
        export PKG_CONFIG_PATH=${PKG_CONFIG_PATH} \
        (etc) \
        ${PYTHON} ${CMD}

mpl_build:
        run_cmd CMD="setup.py build"

mpl_install:
        run_cmd CMD="setup.py install --prefix=${PREFIX}"

mpl_install_std:
        run_cmd CMD="setup.py install"

mpl_develop:
        run_cmd CMD="setupegg.py develop"
------------------------------------------------------------------------

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

OK, if there are no objections I will start making the appropriate changes to the code and the documentation. 
-- Michiel

On Sun Feb 27th, 2011 8:49 AM EST John Hunter wrote:

>On Sun, Feb 27, 2011 at 1:06 AM, Eric Firing <ef...@ha...> wrote:
>
>> That's a good point.  Until fairly recently, interactive behavior worked
>> across backends only via ipython magic, so I think the non-interactive
>> default had a solid historical rationale.  Now, however, we could
>> probably make interactive mode the startup default for interactive
>> backends without causing any problems.  I agree that this would be more
>> intuitive and more familiar to people coming from matlab.
>
>Probably right -- this was a design decision made early on when I did
>not see a good way around the problem that the idle drawing across
>backends now solves.  There will probably be some unintended
>consequences of changing the default, but as long as we document it
>prominently and provide a way for people to change the behavior to the
>old wan in their rc, it is probably a good idea to make this change.
>
>------------------------------------------------------------------------------
>Free Software Download: Index, Search & Analyze Logs and other IT data in 
>Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
>generated by your applications, servers and devices whether physical, virtual
>or in the cloud. Deliver compliance at lower cost and gain new business 
>insights. http://p.sf.net/sfu/splunk-dev2dev 
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel