Pylab import error due to dateutil

Community matplotlib-users
1

Hello,

With a fresh

git clone git://github.com/matplotlib/matplotlib.git

sudo python setupegg.py develop

Starting ipython --pylab I get this error:

…/matplotlib/lib/matplotlib/dates.py in ()

120 import matplotlib.ticker as ticker

121

–> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU, YEARLY, \

123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY

124 from dateutil.relativedelta import relativedelta

ImportError: No module named dateutil.rrule

Installing dateutil 1.5 fixes this.

mpl install log shows the following:

OPTIONAL DATE/TIMEZONE DEPENDENCIES

dateutil: matplotlib will provide

pytz: matplotlib will provide

Will dateutil be shipped with mpl or this line needs to be updated?

Thanks.

···

–
Gökhan

2

This is related to using develop mode. I never use that (I use virtualenvs instead), so this doesn't get much testing. This seems to have broken when we started to ship separate versions of dateutil for python2 and python3. setuptools doesn't seem to like the fact that we rename dateutil_py2 to dateutil when installing (since in develop mode it doesn't really install or move anything). That's problematic, of course. I'll have to see if there's another way to handle this.

Mike

···

On 10/09/2012 09:36 PM, G�khan Sever wrote:

Hello,

With a fresh

git clone git://github.com/matplotlib/matplotlib.git <http://github.com/matplotlib/matplotlib.git&gt;
sudo python setupegg.py develop

Starting ipython --pylab I get this error:

.../matplotlib/lib/matplotlib/dates.py in <module>()
    120 import matplotlib.ticker as ticker
    121
--> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU, YEARLY, \
    123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
    124 from dateutil.relativedelta import relativedelta

ImportError: No module named dateutil.rrule

Installing dateutil 1.5 fixes this.

mpl install log shows the following:

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              dateutil: matplotlib will provide
                  pytz: matplotlib will provide

Will dateutil be shipped with mpl or this line needs to be updated?

Thanks.

--
G�khan

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

3

I think this stack overflow question [1] sort of sums up the problem -- setuptools develop is kind of a hack and only really works if the source structure matches the installed structure. That used to be true of matplotlib, but installing different packages based on the Python version breaks that assumption.

A suggestion in the Stack Overflow entry is to install symlinks to fix this, and indeed doing this works:

    cd lib
    ln -s dateutil_py2 dateutil

We can probably automate this in the setupegg.py script, but I don't think I'll have a chance to get to this today. We can't just include the symlink in git, since it should point to the version that corresponds to the user's Python.

[1] python - Is there a way to add a namespace prefix setuptools package distributions? - Stack Overflow

Mike

···

On 10/10/2012 08:50 AM, Michael Droettboom wrote:

This is related to using develop mode. I never use that (I use virtualenvs instead), so this doesn't get much testing. This seems to have broken when we started to ship separate versions of dateutil for python2 and python3. setuptools doesn't seem to like the fact that we rename dateutil_py2 to dateutil when installing (since in develop mode it doesn't really install or move anything). That's problematic, of course. I'll have to see if there's another way to handle this.

Mike

On 10/09/2012 09:36 PM, G�khan Sever wrote:

Hello,

With a fresh

git clone git://github.com/matplotlib/matplotlib.git <http://github.com/matplotlib/matplotlib.git&gt;
sudo python setupegg.py develop

Starting ipython --pylab I get this error:

.../matplotlib/lib/matplotlib/dates.py in <module>()
    120 import matplotlib.ticker as ticker
    121
--> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU, YEARLY, \
    123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
    124 from dateutil.relativedelta import relativedelta

ImportError: No module named dateutil.rrule

Installing dateutil 1.5 fixes this.

mpl install log shows the following:

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              dateutil: matplotlib will provide
                  pytz: matplotlib will provide

Will dateutil be shipped with mpl or this line needs to be updated?

Thanks.

--
G�khan

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

4

I filed an issue for this. We should try to get the fix into 1.2.x

Mike

···

On 10/10/2012 09:00 AM, Michael Droettboom wrote:

I think this stack overflow question [1] sort of sums up the problem -- setuptools develop is kind of a hack and only really works if the source structure matches the installed structure. That used to be true of matplotlib, but installing different packages based on the Python version breaks that assumption.

A suggestion in the Stack Overflow entry is to install symlinks to fix this, and indeed doing this works:

   cd lib
   ln -s dateutil_py2 dateutil

We can probably automate this in the setupegg.py script, but I don't think I'll have a chance to get to this today. We can't just include the symlink in git, since it should point to the version that corresponds to the user's Python.

[1] python - Is there a way to add a namespace prefix setuptools package distributions? - Stack Overflow

Mike

On 10/10/2012 08:50 AM, Michael Droettboom wrote:

This is related to using develop mode. I never use that (I use virtualenvs instead), so this doesn't get much testing. This seems to have broken when we started to ship separate versions of dateutil for python2 and python3. setuptools doesn't seem to like the fact that we rename dateutil_py2 to dateutil when installing (since in develop mode it doesn't really install or move anything). That's problematic, of course. I'll have to see if there's another way to handle this.

Mike

On 10/09/2012 09:36 PM, G�khan Sever wrote:

Hello,

With a fresh

git clone git://github.com/matplotlib/matplotlib.git <http://github.com/matplotlib/matplotlib.git&gt;
sudo python setupegg.py develop

Starting ipython --pylab I get this error:

.../matplotlib/lib/matplotlib/dates.py in <module>()
    120 import matplotlib.ticker as ticker
    121
--> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU, YEARLY, \
    123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
    124 from dateutil.relativedelta import relativedelta

ImportError: No module named dateutil.rrule

Installing dateutil 1.5 fixes this.

mpl install log shows the following:

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              dateutil: matplotlib will provide
                  pytz: matplotlib will provide

Will dateutil be shipped with mpl or this line needs to be updated?

Thanks.

--
G�khan

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

5

setupegg.py develop is the easiest way for me to install the latest mpl and also ipython from the github repos.

I see that your suggested symlink fix also resolves this issue.

Thanks Mike for looking into this quickly.

···

On Wed, Oct 10, 2012 at 7:09 AM, Michael Droettboom <mdroe@…86…> wrote:

  I filed an issue for this.  We should

try to get the fix into 1.2.x

  [https://github.com/matplotlib/matplotlib/issues/1354](https://github.com/matplotlib/matplotlib/issues/1354)



  Mike




  On 10/10/2012 09:00 AM, Michael Droettboom wrote:

    I think this stack overflow question

[1] sort of sums up the problem – setuptools develop is kind of
a hack and only really works if the source structure matches the
installed structure. That used to be true of matplotlib, but
installing different packages based on the Python version breaks
that assumption.

    A suggestion in the Stack Overflow entry is to install symlinks

to fix this, and indeed doing this works:

       cd lib

       ln -s dateutil_py2 dateutil



    We can probably automate this in the setupegg.py script, but I

don’t think I’ll have a chance to get to this today. We can’t
just include the symlink in git, since it should point to the
version that corresponds to the user’s Python.

    [1] [http://stackoverflow.com/questions/6019042/is-there-a-way-to-add-a-namespace-prefix-setuptools-package-distributions](http://stackoverflow.com/questions/6019042/is-there-a-way-to-add-a-namespace-prefix-setuptools-package-distributions)




    Mike



    On 10/10/2012 08:50 AM, Michael Droettboom wrote:

      This is related to using develop

mode. I never use that (I use virtualenvs instead), so this
doesn’t get much testing. This seems to have broken when we
started to ship separate versions of dateutil for python2 and
python3. setuptools doesn’t seem to like the fact that we
rename dateutil_py2 to dateutil when installing (since in
develop mode it doesn’t really install or move anything).
That’s problematic, of course. I’ll have to see if there’s
another way to handle this.

      Mike



      On 10/09/2012 09:36 PM, Gökhan Sever wrote:

Hello,

With a fresh

git clone git://github.com/matplotlib/matplotlib.git

sudo python setupegg.py develop

Starting ipython --pylab I get this error:

          .../matplotlib/lib/matplotlib/dates.py in

()

120 import matplotlib.ticker as ticker

121

          --> 122 from dateutil.rrule import rrule, MO, TU,

WE, TH, FR, SA, SU, YEARLY, \

          123      MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY,

SECONDLY

          124 from dateutil.relativedelta import

relativedelta

ImportError: No module named dateutil.rrule

Installing dateutil 1.5 fixes this.

mpl install log shows the following:

OPTIONAL DATE/TIMEZONE DEPENDENCIES

dateutil: matplotlib will provide

pytz: matplotlib will provide

          Will dateutil be shipped with mpl or this line needs to

be updated?

Thanks.

–

        Gökhan

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
[http://p.sf.net/sfu/newrelic-dev2dev](http://p.sf.net/sfu/newrelic-dev2dev)

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
[https://lists.sourceforge.net/lists/listinfo/matplotlib-users](https://lists.sourceforge.net/lists/listinfo/matplotlib-users)

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
[http://p.sf.net/sfu/newrelic-dev2dev](http://p.sf.net/sfu/newrelic-dev2dev)

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
[https://lists.sourceforge.net/lists/listinfo/matplotlib-users](https://lists.sourceforge.net/lists/listinfo/matplotlib-users)

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
[http://p.sf.net/sfu/newrelic-dev2dev](http://p.sf.net/sfu/newrelic-dev2dev)

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
[https://lists.sourceforge.net/lists/listinfo/matplotlib-users](https://lists.sourceforge.net/lists/listinfo/matplotlib-users)

Don’t let slow site performance ruin your business. Deploy New Relic APM

Deploy New Relic app performance management and know exactly

what is happening inside your Ruby, Python, PHP, Java, and .NET app

Try New Relic at no cost today and get our sweet Data Nerd shirt too!

http://p.sf.net/sfu/newrelic-dev2dev

Matplotlib-users mailing list

Matplotlib-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-users

–
Gökhan

6

Gökhan, did you implement the symlink fix? If so, would you mind
making a pull request out of it? I was just about to look into doing
this, but if you've done it already that'd save us some effort rolling
out fixes for 1.2.

Cheers.
Damon

···

On Wed, Oct 10, 2012 at 3:09 PM, Michael Droettboom <mdroe@...86...> wrote:

I filed an issue for this. We should try to get the fix into 1.2.x

setupegg.py develop is broken · Issue #1354 · matplotlib/matplotlib · GitHub

Mike

On 10/10/2012 09:00 AM, Michael Droettboom wrote:

I think this stack overflow question [1] sort of sums up the problem --
setuptools develop is kind of a hack and only really works if the source
structure matches the installed structure. That used to be true of
matplotlib, but installing different packages based on the Python version
breaks that assumption.

A suggestion in the Stack Overflow entry is to install symlinks to fix this,
and indeed doing this works:

   cd lib
   ln -s dateutil_py2 dateutil

We can probably automate this in the setupegg.py script, but I don't think
I'll have a chance to get to this today. We can't just include the symlink
in git, since it should point to the version that corresponds to the user's
Python.

[1]
python - Is there a way to add a namespace prefix setuptools package distributions? - Stack Overflow

Mike

On 10/10/2012 08:50 AM, Michael Droettboom wrote:

This is related to using develop mode. I never use that (I use virtualenvs
instead), so this doesn't get much testing. This seems to have broken when
we started to ship separate versions of dateutil for python2 and python3.
setuptools doesn't seem to like the fact that we rename dateutil_py2 to
dateutil when installing (since in develop mode it doesn't really install or
move anything). That's problematic, of course. I'll have to see if there's
another way to handle this.

Mike

On 10/09/2012 09:36 PM, Gökhan Sever wrote:

Hello,

With a fresh

git clone git://github.com/matplotlib/matplotlib.git
sudo python setupegg.py develop

Starting ipython --pylab I get this error:

.../matplotlib/lib/matplotlib/dates.py in <module>()
    120 import matplotlib.ticker as ticker
    121
--> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU,
YEARLY, \
    123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
    124 from dateutil.relativedelta import relativedelta

ImportError: No module named dateutil.rrule

Installing dateutil 1.5 fixes this.

mpl install log shows the following:

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              dateutil: matplotlib will provide
                  pytz: matplotlib will provide

Will dateutil be shipped with mpl or this line needs to be updated?

Thanks.

--
Gökhan

--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

7

Hi Damon,

I think adding these lines before execfile line in setupegg.py should fix it:

import os

os.chdir(‘lib’)

if not os.path.isdir(‘dateutil’):

os.symlink(‘dateutil_py2’, ‘dateutil’)

os.chdir(‘…’)

Could you give it a test? Do we require a similar symlink for py3?

Thanks.

···

On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall <damon.mcdougall@…287…> wrote:

Gökhan, did you implement the symlink fix? If so, would you mind

making a pull request out of it? I was just about to look into doing

this, but if you’ve done it already that’d save us some effort rolling

out fixes for 1.2.

Cheers.

Damon

–
Gökhan

8

Awesome. I’ll give it a go later on. I’m a little concerned using os.chdir. I think Peter Wuertz/Chris Gohlke had problems with it not being threadsafe on windows. Does the same apply here?

···

On Thursday, October 11, 2012, Gökhan Sever wrote:

On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall <damon.mcdougall@…287…> wrote:

Gökhan, did you implement the symlink fix? If so, would you mind

making a pull request out of it? I was just about to look into doing

this, but if you’ve done it already that’d save us some effort rolling

out fixes for 1.2.

Cheers.

Damon

Hi Damon,

I think adding these lines before execfile line in setupegg.py should fix it:

import os

os.chdir(‘lib’)

if not os.path.isdir(‘dateutil’):

os.symlink(‘dateutil_py2’, ‘dateutil’)

os.chdir(‘…’)

Could you give it a test? Do we require a similar symlink for py3?

Thanks.

–
Gökhan

–
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL

United Kingdom

9

I am not sure about that technical detail, but it works fine here on my Fedora 16 (x86_64) system.

···

On Thu, Oct 11, 2012 at 11:04 AM, Damon McDougall <damon.mcdougall@…287…> wrote:

On Thursday, October 11, 2012, Gökhan Sever wrote:

On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall <damon.mcdougall@…287…> wrote:

Gökhan, did you implement the symlink fix? If so, would you mind

making a pull request out of it? I was just about to look into doing

this, but if you’ve done it already that’d save us some effort rolling

out fixes for 1.2.

Cheers.

Damon

Hi Damon,

I think adding these lines before execfile line in setupegg.py should fix it:

import os

os.chdir(‘lib’)

if not os.path.isdir(‘dateutil’):

os.symlink(‘dateutil_py2’, ‘dateutil’)

os.chdir(‘…’)

Could you give it a test? Do we require a similar symlink for py3?

Thanks.

–
Gökhan

Awesome. I’ll give it a go later on. I’m a little concerned using os.chdir. I think Peter Wuertz/Chris Gohlke had problems with it not being threadsafe on windows. Does the same apply here?

–
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL

United Kingdom

–
Gökhan

10

I'm not sure how to test this. I'm running `setupegg.py develop` from
within a python virtual env, but somehow it's picking up dateutil
version 1.5. I don't get the `matplotlib will provide` message... Hmm.

···

On Thu, Oct 11, 2012 at 9:25 PM, Gökhan Sever <gokhansever@...287...> wrote:

I am not sure about that technical detail, but it works fine here on my
Fedora 16 (x86_64) system.

On Thu, Oct 11, 2012 at 11:04 AM, Damon McDougall > <damon.mcdougall@...287...> wrote:

On Thursday, October 11, 2012, Gökhan Sever wrote:

On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall >>> <damon.mcdougall@...287...> wrote:

Gökhan, did you implement the symlink fix? If so, would you mind
making a pull request out of it? I was just about to look into doing
this, but if you've done it already that'd save us some effort rolling
out fixes for 1.2.

Cheers.
Damon

Hi Damon,

I think adding these lines before execfile line in setupegg.py should fix
it:

import os
os.chdir('lib')
if not os.path.isdir('dateutil'):
    os.symlink('dateutil_py2', 'dateutil')
os.chdir('..')

Could you give it a test? Do we require a similar symlink for py3?

Thanks.

--
Gökhan

Awesome. I'll give it a go later on. I'm a little concerned using
os.chdir. I think Peter Wuertz/Chris Gohlke had problems with it not being
threadsafe on windows. Does the same apply here?

--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

11

Thanks for taking this on, Damon and G�khan.

Note this will need to create a different symlink (to dateutil_py3 instead) on Python 3. This means, of course, that it will be impossible to develop on both Python 2 and 3 simultaneously, but that's true of "setuptools' develop" in any event, so it's no great loss.

Mike

···

On 10/11/2012 03:38 PM, Damon McDougall wrote:

On Thu, Oct 11, 2012 at 9:25 PM, G�khan Sever <gokhansever@...287...> wrote:

I am not sure about that technical detail, but it works fine here on my
Fedora 16 (x86_64) system.

On Thu, Oct 11, 2012 at 11:04 AM, Damon McDougall >> <damon.mcdougall@...287...> wrote:

On Thursday, October 11, 2012, G�khan Sever wrote:

On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall >>>> <damon.mcdougall@...287...> wrote:

G�khan, did you implement the symlink fix? If so, would you mind
making a pull request out of it? I was just about to look into doing
this, but if you've done it already that'd save us some effort rolling
out fixes for 1.2.

Cheers.
Damon

Hi Damon,

I think adding these lines before execfile line in setupegg.py should fix
it:

import os
os.chdir('lib')
if not os.path.isdir('dateutil'):
     os.symlink('dateutil_py2', 'dateutil')
os.chdir('..')

Could you give it a test? Do we require a similar symlink for py3?

Thanks.

--
G�khan

Awesome. I'll give it a go later on. I'm a little concerned using
os.chdir. I think Peter Wuertz/Chris Gohlke had problems with it not being
threadsafe on windows. Does the same apply here?

I'm not sure how to test this. I'm running `setupegg.py develop` from
within a python virtual env, but somehow it's picking up dateutil
version 1.5. I don't get the `matplotlib will provide` message... Hmm.