matplotlib-users Mailing List for matplotlib

On Nov 8, 2010, at 9:51 AM, Ryan May wrote:

> On Mon, Nov 8, 2010 at 8:34 AM, Philip Semanchuk <ph...@se...> wrote:
>> Hi Ryan,
>> Thanks. I don't know why sudo behaves the way it does with regard to $HOME, but the behavior of sudo is not under my control (nor matplotlib's). Also, I expect that *lots* of software depends on this behavior of sudo so changing it is probably not an option.
>> 
> 
> Sounds like you've found your solution (which is great), but to set
> the record straight, you *can* control the behavior of sudo. In
> /etc/sudoers, you can set env_reset to reset the environment, so none
> of your variables (like $HOME). You can also just specify certain
> variables to be reset. There is also an option always_set_home which
> seems to do the right thing. In fact, on my machine, sudo works just
> fine:
> 
> ~> sudo python -c 'import os;print os.environ["HOME"]'
> /root
> 
> So, so long as you can edit /etc/sudoers, you are *very much* in
> control of how sudo works in this regard.


Thanks for the education, Ryan. 

I checked my Ubuntu 9.04 virtual install where I first saw this problem, and the contents of /etc/sudoers  are as described here:
https://help.ubuntu.com/community/Sudoers#The%20Default%20Ubuntu%20Sudoers%20File

Sure enough, $HOME isn't altered by sudo:
~$ sudo python -c 'import os;print os.environ["HOME"]'
/home/philip

I observe the same under OS X, so this configuration of /etc/sudoers might not be ideal, but it's popular.


Thanks
P

I like to have 2 or 3 text elements "stacked" on top of each other on 
top of a bar.

Currently it works for the first text element by doing:

height = bar.get_height()
xCorr = bar.get_x()
yCorr = 0.20 + height

txtax = axes.text(xCorr, yCorr, hstr)

trying to add the second text just above the previous one I tried this:

pCorr = yCorr + txtax.get_size() + 0.4
txtax = axes.text(xCorr, pCorr, hstrPerc)

It looks like my problem is that get_x() returns a value in ticks and 
txtax.get_size() is in pixels and I can't find a way to get at the 
height of the text element in ticks.

Can anyone please push me in the right direction.

Werner

On Mon, Nov 8, 2010 at 8:34 AM, Philip Semanchuk <ph...@se...> wrote:
> Hi Ryan,
> Thanks. I don't know why sudo behaves the way it does with regard to $HOME, but the behavior of sudo is not under my control (nor matplotlib's). Also, I expect that *lots* of software depends on this behavior of sudo so changing it is probably not an option.
>

Sounds like you've found your solution (which is great), but to set
the record straight, you *can* control the behavior of sudo. In
/etc/sudoers, you can set env_reset to reset the environment, so none
of your variables (like $HOME). You can also just specify certain
variables to be reset. There is also an option always_set_home which
seems to do the right thing. In fact, on my machine, sudo works just
fine:

~> sudo python -c 'import os;print os.environ["HOME"]'
/root

So, so long as you can edit /etc/sudoers, you are *very much* in
control of how sudo works in this regard.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Nov 8, 2010, at 9:13 AM, Ryan May wrote:

> On Thu, Nov 4, 2010 at 10:49 AM, Philip Semanchuk <ph...@se...> wrote:
>> Hi all,
>> I've run into an aspect of matplotlib's setup that seems awkward. I'm seeing this on Ubuntu, but I imagine it would happen on any *nix platform.
>> 
>> If python is running under sudo the first time matplotlib is imported, then matplotlib creates its config dir (~/.matplotlib) with root as the owner. Subsequent attempts to import matplotlib while running python as a non-privileged user result in this:
>> 
>> -----------------------------------------------------------------
>> RuntimeError: '/home/philip' is not a writable dir; you must set /home/philip/.matplotlib to be a writable dir.  You can also set environment variable MPLCONFIGDIR to any writable directory where you want matplotlib data stored
>> -----------------------------------------------------------------
>> 
>> A simple way to re-create this --
>> 1. Delete or rename ~/.matplotlib
>> 2. sudo python -c "import matplotlib"
>> 3. python -c "import matplotlib"
>> 
>> 
>> This not-improbable real-world scenario would create ~/.matplotlib owned by root  --
>> 1) Download app FooBar that has matplotlib as a dependency
>> 2) Install matplotlib
>> 3) Run FooBar's setup.py as sudo. It imports matplotlib, perhaps just to ensure that matplotlib is installed and working.
>> 
>> 
>> We ran into a similar situation with our app ('sudo python setup.py install' created desktop icons owned by root) and we resolved it by invoking chown after using a getenv() call to sniff out who we really wanted to own the file.
>> 
>> It looks like the diff below (untested!) applied to lib/matplotlib/__init__.py would prevent this from happening. Does it seems reasonable to add it?
>> 
>> 474a475,485
>>>         if not sys.platform.lower().startswith("win"):
>>>             # Ensure that we didn't just create a root-owned directory in the
>>>             # user's HOME directory. That happens if this is being run under
>>>             # sudo. If the SUDO_USER env. var (which contains the user that
>>>             # invoked sudo) then we're running under sudo. If it doesn't
>>>             # exist, we're not running under sudo.
>>>             current_user = os.getenv("SUDO_USER")
>>>             if current_user:
>>>                 subprocess.call(["chown", "-R", current_user, p])
> 
> I'm not sure how I feel about this. On one hand, it is a pain to have
> this not work under sudo. On the other, I consider the fact that $HOME
> is not set to "/root" when running as root to be a bit of a problem.
> Personally, the better solution to me would be to make sure $HOME is
> one of the variables that gets reset by sudo.

Hi Ryan,
Thanks. I don't know why sudo behaves the way it does with regard to $HOME, but the behavior of sudo is not under my control (nor matplotlib's). Also, I expect that *lots* of software depends on this behavior of sudo so changing it is probably not an option.

@Matthieu --

Merci Matthieu, yours is an elegant solution. In our setup.py we're just importing matplotlib to ensure it exists, so that fits your scenario. 

The workaround I used was this --

    MATPLOTLIB_CONFIG_PATH = os.path.join(os.path.expanduser('~'), ".matplotlib")

    if not sys.platform.lower().startswith("win"):
        if not os.path.exists(MATPLOTLIB_CONFIG_PATH):
            check_matplotlib_permissions = True
        
        
    # Do stuff that triggers an import of matplotlib...


    if check_matplotlib_permissions:
        if os.path.exists(MATPLOTLIB_CONFIG_PATH):
            sudo_user = os.getenv("SUDO_USER")
            if sudo_user:
                subprocess.call(["chown", "-R", sudo_user, MATPLOTLIB_CONFIG_PATH])


I think I like your idea better.


Cheers
Philip

PS - Matthieu, sorry for not quoting you directly but I was unable to subscribe to the list before I received your mail.

On Thu, Nov 4, 2010 at 10:49 AM, Philip Semanchuk <ph...@se...> wrote:
> Hi all,
> I've run into an aspect of matplotlib's setup that seems awkward. I'm seeing this on Ubuntu, but I imagine it would happen on any *nix platform.
>
> If python is running under sudo the first time matplotlib is imported, then matplotlib creates its config dir (~/.matplotlib) with root as the owner. Subsequent attempts to import matplotlib while running python as a non-privileged user result in this:
>
> -----------------------------------------------------------------
> RuntimeError: '/home/philip' is not a writable dir; you must set /home/philip/.matplotlib to be a writable dir.  You can also set environment variable MPLCONFIGDIR to any writable directory where you want matplotlib data stored
> -----------------------------------------------------------------
>
> A simple way to re-create this --
> 1. Delete or rename ~/.matplotlib
> 2. sudo python -c "import matplotlib"
> 3. python -c "import matplotlib"
>
>
> This not-improbable real-world scenario would create ~/.matplotlib owned by root  --
> 1) Download app FooBar that has matplotlib as a dependency
> 2) Install matplotlib
> 3) Run FooBar's setup.py as sudo. It imports matplotlib, perhaps just to ensure that matplotlib is installed and working.
>
>
> We ran into a similar situation with our app ('sudo python setup.py install' created desktop icons owned by root) and we resolved it by invoking chown after using a getenv() call to sniff out who we really wanted to own the file.
>
> It looks like the diff below (untested!) applied to lib/matplotlib/__init__.py would prevent this from happening. Does it seems reasonable to add it?
>
> 474a475,485
>>         if not sys.platform.lower().startswith("win"):
>>             # Ensure that we didn't just create a root-owned directory in the
>>             # user's HOME directory. That happens if this is being run under
>>             # sudo. If the SUDO_USER env. var (which contains the user that
>>             # invoked sudo) then we're running under sudo. If it doesn't
>>             # exist, we're not running under sudo.
>>             current_user = os.getenv("SUDO_USER")
>>             if current_user:
>>                 subprocess.call(["chown", "-R", current_user, p])

I'm not sure how I feel about this. On one hand, it is a pain to have
this not work under sudo. On the other, I consider the fact that $HOME
is not set to "/root" when running as root to be a bit of a problem.
Personally, the better solution to me would be to make sure $HOME is
one of the variables that gets reset by sudo.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

If you don't have any special use for the config dir, this might be a 
more straightforward solution that doesn't require patching matplotlib.

Simply paste this in your code, before importing matplotlib :

import os
os.environ['HOME'] = '/tmp/'


Might be safer to use 'MPLCONFIGDIR' instead of 'HOME'.

Hope this helps.

Matthieu

Le 04/11/2010 16:49, Philip Semanchuk a écrit :
> Hi all,
> I've run into an aspect of matplotlib's setup that seems awkward. I'm seeing this on Ubuntu, but I imagine it would happen on any *nix platform.
>
> If python is running under sudo the first time matplotlib is imported, then matplotlib creates its config dir (~/.matplotlib) with root as the owner. Subsequent attempts to import matplotlib while running python as a non-privileged user result in this:
>
> -----------------------------------------------------------------
> RuntimeError: '/home/philip' is not a writable dir; you must set /home/philip/.matplotlib to be a writable dir.  You can also set environment variable MPLCONFIGDIR to any writable directory where you want matplotlib data stored
> -----------------------------------------------------------------
>
> A simple way to re-create this --
> 1. Delete or rename ~/.matplotlib
> 2. sudo python -c "import matplotlib"
> 3. python -c "import matplotlib"
>
>
> This not-improbable real-world scenario would create ~/.matplotlib owned by root  --
> 1) Download app FooBar that has matplotlib as a dependency
> 2) Install matplotlib
> 3) Run FooBar's setup.py as sudo. It imports matplotlib, perhaps just to ensure that matplotlib is installed and working.
>
>
> We ran into a similar situation with our app ('sudo python setup.py install' created desktop icons owned by root) and we resolved it by invoking chown after using a getenv() call to sniff out who we really wanted to own the file.
>
> It looks like the diff below (untested!) applied to lib/matplotlib/__init__.py would prevent this from happening. Does it seems reasonable to add it?
>
> 474a475,485
>>          if not sys.platform.lower().startswith("win"):
>>              # Ensure that we didn't just create a root-owned directory in the
>>              # user's HOME directory. That happens if this is being run under
>>              # sudo. If the SUDO_USER env. var (which contains the user that
>>              # invoked sudo) then we're running under sudo. If it doesn't
>>              # exist, we're not running under sudo.
>>              current_user = os.getenv("SUDO_USER")
>>              if current_user:
>>                  subprocess.call(["chown", "-R", current_user, p])
>
> Thanks
> Philip
>
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,

I am pleased to announce the release of pywcsgrid2 0.1b1.

pywcsgrid2 is a python module to be used with matplotlib for
displaying astronomical fits images. It provides a custom Axes class
(derived from mpl's original Axes class) suitable for displaying fits
images. Its main functionality is to draw ticks, ticklabels, and grids
in an appropriate sky coordinates.

For a sampling, take a look at the gallery

http://leejjoon.github.com/matplotlib_astronomy_gallery/


 * Provide a custom Matplotlib Axes class based on
mpl_toolkits.axisartist module

 * Easy integration with mpl_toolkits.axes_grid1 module

Requirement
------------------

 * matplotlib v1.0 (or later)
 * a wcs module (pywcs or Kapteyn)
 * pyfits.

Supported OS
--------------------
 * Linux & OS X
 * pywcsgrid2 itself is a pure python module.


URLs
------

Home page : http://leejjoon.github.com/pywcsgrid2/

Overview doc. : http://leejjoon.github.com/pywcsgrid2/users/overview.html

Download : http://github.com/leejjoon/pywcsgrid2/downloads

github : http://github.com/leejjoon/pywcsgrid2

For questions, bug reports or feature suggestions, please use the
issue tracker in the github or contact me via email.

Regards,

-JJ