# afw tests fail if user has (incompatible) local version of matplotlib

XMLWordPrintable

## Details

• Type: Bug
• Status: Won't Fix
• Resolution: Done
• Fix Version/s: None
• Component/s: None
• Labels:
None
• Team:
SQuaRE

## Description

testAstropyTableViews and testMakeRGB in afw fail on my RHEL6 system where I have a different (incompatible) version of astropy and matplotlib installed in my ~/.local/lib. (Though I note that both crash with the same "undefined symbol: PyUnicodeUCS2_AsEncodedString")

Should .local override these packages? (I don't know the answer to this in a specific or general sense.)

## Activity

Hide
Tim Jenness added a comment -

PEP-370 defines the order for module importing. The order is PYTHONPATH, ~/.local, python system. This order seems pretty sensible to me but you hit problems if your local packages are built with a different Python. Were your local packages built with Python 2.7?

Tests should not fail because of local override packages if we are using a python we installed. If we are using an external python that python probably expects those local packages so it's not completely obvious we can switch sconsUtils to run python -s to disable the local packages. I'm also not sure if it is possible to disable local packages within py.test.

I think it might be best for you to switch to virtualenv so your local packages are associated with a specific Python installation.

Show
Tim Jenness added a comment - PEP-370 defines the order for module importing. The order is PYTHONPATH , ~/.local , python system. This order seems pretty sensible to me but you hit problems if your local packages are built with a different Python. Were your local packages built with Python 2.7? Tests should not fail because of local override packages if we are using a python we installed. If we are using an external python that python probably expects those local packages so it's not completely obvious we can switch sconsUtils to run python -s to disable the local packages. I'm also not sure if it is possible to disable local packages within py.test . I think it might be best for you to switch to virtualenv so your local packages are associated with a specific Python installation.
Hide
Tim Jenness added a comment -

The safest option may be to ensure that if the external environment has set the $PYTHONNOUSERSITE environment variable that that variable is propagated to the test system within sconsUtils. Show Tim Jenness added a comment - The safest option may be to ensure that if the external environment has set the$PYTHONNOUSERSITE environment variable that that variable is propagated to the test system within sconsUtils .
Hide
Eli Rykoff added a comment -

These are all built with python 2.7, otherwise it wouldn't find them in right (sub)-directory. But there are apparently subtle incompatibilities, of course. I will look into virtualenv.

Show
Eli Rykoff added a comment - These are all built with python 2.7, otherwise it wouldn't find them in right (sub)-directory. But there are apparently subtle incompatibilities, of course. I will look into virtualenv .
Hide
John Swinbank added a comment -

I think this is a packaging and/or documentation issue, so I'm setting the team to SQuaRE. Please feel free to send it somewhere else if you disagree.

Show
John Swinbank added a comment - I think this is a packaging and/or documentation issue, so I'm setting the team to SQuaRE. Please feel free to send it somewhere else if you disagree.
Hide
John Swinbank added a comment -

3.5 years later I'm assuming Eli is safely using Virtualenv (or whatever), and nobody else has run into this issue, so I'm closing it. Please reopen if this is actually still a problem.

Show
John Swinbank added a comment - 3.5 years later I'm assuming Eli is safely using Virtualenv (or whatever), and nobody else has run into this issue, so I'm closing it. Please reopen if this is actually still a problem.

## People

• Assignee:
Unassigned
Reporter:
Eli Rykoff
Watchers:
Eli Rykoff, John Swinbank, Jonathan Sick, Tim Jenness