PermissionError: [Errno 13] Permission denied: 'skyfield-1.16-py3.8.egg/skyfield/data/nutation.npz'

On a fresh install of the Skyfield library, the import the timelib module fails with the following stack trace:

Traceback (most recent call last):
  File "/usr/bin/kosmorro", line 24, in <module>
    from kosmorrolib import dumper
  File "/usr/lib/python3.8/site-packages/kosmorrolib/dumper.py", line 23, in <module>
    from skyfield.timelib import Time
  File "/usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/timelib.py", line 10, in <module>
    from .nutationlib import compute_nutation, earth_tilt, iau2000a
  File "/usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/nutationlib.py", line 6, in <module>
    _arrays = load_bundled_npy('nutation.npz')
  File "/usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/functions.py", line 124, in load_bundled_npy
    data = get_data('skyfield', 'data/{0}'.format(filename))
  File "/usr/lib/python3.8/pkgutil.py", line 637, in get_data
    return loader.get_data(resource_name)
  File "<frozen importlib._bootstrap_external>", line 972, in get_data
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/data/nutation.npz'

I checked the files in the /usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/data/nutation.npz and found out that most of them (but not all) are missing the read permission, making it impossible to read them unless running as root:

$ ls -l /usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/data
total 84
drwxr-xr-x 1 root root   434 12 janv. 09:57 .
drwxr-xr-x 1 root root   830 12 janv. 09:57 ..
-rw-r----- 1 root root  3595 12 janv. 09:57 constellations.npz
-rw-r----- 1 root root 11697 12 janv. 09:57 deltat.data
-rw-r----- 1 root root  2237 12 janv. 09:57 deltat.preds
-rw-r--r-- 1 root root  1354 12 janv. 09:57 earth_orientation.py
-rw-r--r-- 1 root root  2453 12 janv. 09:57 gravitational_parameters.py
-rw-r--r-- 1 root root  2798 12 janv. 09:57 hipparcos.py
-rw-r----- 1 root root 10576 12 janv. 09:57 historic_deltat.npy
-rw-r--r-- 1 root root   706 12 janv. 09:57 horizons.py
-rw-r--r-- 1 root root    72 12 janv. 09:57 __init__.py
-rw-r----- 1 root root  1352 12 janv. 09:57 Leap_Second.dat
-rw-r----- 1 root root   528 12 janv. 09:57 morrison_stephenson_deltat.npy
-rw-r----- 1 root root 15728 12 janv. 09:57 nutation.npz
drwxr-xr-x 1 root root   322 12 janv. 09:57 __pycache__
-rw-r--r-- 1 root root  4682 12 janv. 09:57 spice.py

As a temporary fix, the missing permission to the others group can be added:

$ sudo chmod o+r /usr/lib/python3.8/site-packages/skyfield-1.16-py3.8.egg/skyfield/data/*

Running Python 3.8.1 on Arch Linux. The same issue happens whenever I install Skyfield through PyPI or the AUR.

[brandon-rhodes]

I’m glad it’s working again! I’m going to close this for now, but feel free to re-open if the problem reappears, or if you notice what made the difference between a working and not-working installation.

[brandon-rhodes]

Welp. It’s a bug in distutils!

https://github.com/kjd/idna/issues/66#issuecomment-398007302

Apparently the fact that I don’t have public permissions set on my personal computer (because I use the same dotfiles on Linux machines that have other users besides me) means that everyone installing the wheel gets my private permission decisions imposed on them.

I wonder how I can fix this systematically, for all the Python packages I distribute? I assume that, for example, jplephem also — oh, but maybe it for some reason only happens to data files? Anyway, I’ll probably switch to a more generous umask but then have a way to keep my home directory with a permission of o-x so that no one can get it to my files to begin with.

Feels fragile, but otherwise I’d somehow have to either hijack every setup.py file I run to change the umask, or else remember to always run a special script before doing distributions. I suspect that would be more prone to error.

Let’s leave this open until I release Skyfield again (hopefully later this week), at which point we can verify whether the permissions issues are fixed.