Repository navigation
pip install problem - owner of .astropy is root - #867
Conversation
|
I've heard this from several other users, so I can confirm this is indeed something that we should fix. |
|
I thought the |
|
My experience might help with debugging: I had this happen on one of my computers but not the other, both running OSX 10.8.2, same python distribution, etc. The problem came up only on the computer where I accidentally did |
|
I tested this out, and after completely deleting my Installing with pip should be result in anything being written to my home directory. |
|
Note: This is not just an issue with pip. Running |
|
Could someone give the above fix a try? The pip end of things can be tested by running |
|
I particularly like the fact that this PR raises exceptions if C extensions can't be found and we're not in setup mode. We need to do that in any case. I tried this out. I did the following: |
|
Indeed--if you wanted you could even log more helpful errors if a C extension fails to import for some reason. But that's not really related to this issue. |
|
Apparently this is blowing up for Python 3.x. I didn't realized that the |
|
For what it's worth it seems to work if I change the except statement in |
There was a problem hiding this comment.
I'm not understanding how you're getting away from using this?
There was a problem hiding this comment.
This branch isn't even reached if _ASTROPY_SETUP_ == True. In https://github.com/astropy/astropy/pull/867/files#L5R567 I changed the astropy.cfg generation to still behave as though it's running in "SETUP" mode (which really, it is). But that's what also necessitated changes like https://github.com/astropy/astropy/pull/867/files#L3R15. Now when the generate_config runs, those imports will succeed. They're always attempted, but only allowed to fail if not in "SETUP" mode (where it's possible for them to fail if the extension modules haven't been built yet).
There was a problem hiding this comment.
Ok, I get it now. That seems cleaner anyway.
setup.py install (and in particular when installing Astropy with pip)
the ~/.astropy directory gets generated, when really it shouldn't be.
This commit does a few different things:
* I've never been too thrilled about having code that can modify the
system at import time. In the case of generating the default
astropy.cfg and log I think we have a reasonable excuse, but let's
try to keep stuff like that in astropy/__init__.py: For that reason I
moved the logger module initialization code to an `_init_log()`
function which is called in ``astropy.__init__``. I also set up a
default dummy-log so that stuff like ``from astropy import log`` will
always work even if the real logger hasn't been initialized.
* For the default config generation I got rid of the environment
variable hack and just set ``_ASTROPY_SETUP_`` when running the
subprocess.
* This requires changing the imports that are only performed when
``not _ASTROPY_SETUP_`` to be at least attempted, and only raise an
exception if we're not in setup mode (this way when the default
config generator gets to those imports they will still work).
* Ensured that no attempt is made to create a config file if
``_ASTROPY_SETUP_``.
…o through much of astropy.io.fits and make it at least *importable* under Python 3, since the only places the wcs module was having issues was where it imports from io.fits.
|
Rerunning the Travis build for this because it blew up for weird reasons. |
…make in Astropy than in pyfits, which still supports Python 2.5
|
Great well I think this should be fixed now, but will Travis ever run the tests? |
|
Okay, travis passed except for the |
pip install problem - owner of .astropy is root
|
@mwcraig @astrofrog @destrys - can you see if these changes fixed the problem for you? (this has been merged, so you can use master, or the 0.2.1 version @iguananaut will put out very soon) I ask mainly because there are other ways |
pip install problem - owner of .astropy is root Conflicts: astropy/utils/timer.py
|
0.2.1 worked for me, thanks! |
|
😌💨 |
…stropy#867 I put some things in the wrong order.
I installed astropy with pip:
sudo pip install astropywhich seemed ok.
but when importing astropy:
Changing the owner from root to my username for /Users/username/.astropy/ seems to have fixed the problem.
I'm using python2.7.2 from enthought, numpy 1.7, and I'm on a mac 10.8.2