Menu
▾
▴
matplotlib-users
|
From: Gökhan S. <gok...@gm...> - 2012-10-10 01:36:38
|
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 |
|
From: Michael D. <md...@st...> - 2012-10-10 12:50:19
|
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> > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
|
From: Michael D. <md...@st...> - 2012-10-10 13:00:29
|
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
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>
>> 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
>> Mat...@li...
>> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
|
|
From: Michael D. <md...@st...> - 2012-10-10 13:09:14
|
I filed an issue for this. We should try to get the fix into 1.2.x 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 > > 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> >>> 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 >>> Mat...@li... >>> 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 >> Mat...@li... >> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
|
From: Gökhan S. <gok...@gm...> - 2012-10-10 18:16:42
|
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 <md...@st...> 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 > > 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 > > 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 > > > ------------------------------------------------------------------------------ > 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 lis...@li...://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 lis...@li...://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 lis...@li...://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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > -- Gökhan |
|
From: Damon M. <dam...@gm...> - 2012-10-11 09:50:02
|
On Wed, Oct 10, 2012 at 3:09 PM, Michael Droettboom <md...@st...> 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 > > 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 > > 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 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 -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom |
|
From: Gökhan S. <gok...@gm...> - 2012-10-11 16:50:51
|
On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall
<dam...@gm...>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
|
|
From: Damon M. <dam...@gm...> - 2012-10-11 17:04:40
|
On Thursday, October 11, 2012, Gökhan Sever wrote:
>
>
> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall <
> dam...@gm... <javascript:_e({}, 'cvml',
> 'dam...@gm...');>> 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
|
|
From: Gökhan S. <gok...@gm...> - 2012-10-11 19:26:09
|
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 <dam...@gm...
> wrote:
>
>
> On Thursday, October 11, 2012, Gökhan Sever wrote:
>
>>
>>
>> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall <
>> dam...@gm...> 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
|
|
From: Damon M. <dam...@gm...> - 2012-10-11 19:38:08
|
On Thu, Oct 11, 2012 at 9:25 PM, Gökhan Sever <gok...@gm...> 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
> <dam...@gm...> wrote:
>>
>>
>>
>> On Thursday, October 11, 2012, Gökhan Sever wrote:
>>>
>>>
>>>
>>> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall
>>> <dam...@gm...> 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.
--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
|
|
From: Michael D. <md...@st...> - 2012-10-11 21:45:27
|
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 <gok...@gm...> 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
>> <dam...@gm...> wrote:
>>>
>>>
>>> On Thursday, October 11, 2012, Gökhan Sever wrote:
>>>>
>>>>
>>>> On Thu, Oct 11, 2012 at 3:49 AM, Damon McDougall
>>>> <dam...@gm...> 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.
>
|
