Determine why PLY 3.9 started over-writing the unit tables #5581

Activity

1. eteq

   added

   Effort-medium

   Package-expert

   units

   on Dec 9, 2016
2. eteq

   assigned

   bsipocz

   on Dec 9, 2016
3. eteq commented on Dec 9, 2016

   

   eteq

   on Dec 9, 2016

   MemberAuthor

   More actions

   I assigned @bsipocz as the author of #5563, but if anyone else has ideas, would love to hear it!
4. bsipocz commented on Dec 9, 2016

   

   bsipocz

   on Dec 9, 2016

   Member

   More actions

   Some details: the table regenerating happens only in python2, and only for the generic unit tables and somewhere at the beginning when one runs setup.py.

   PLY is used 3 other places and none of those are showing this issue.
5. bsipocz commented on Dec 29, 2016

   

   bsipocz

   on Dec 29, 2016

   Last edited by bsipocz

   Member

   More actions

   I got a bug report via e-mail that is closely related to #5563. Apparently it's not only the generic unit parsing tables that are regenerated:

   >import astropy.units as u
   >from astropy.time import Time
   >t = Time('2006-01-15 21:24:37.5', scale='utc', location=('120d', '45d'))
   WARNING: Couldn't write lextab module u'angle_lextab'. [Errno 13] Permission denied: u'/usr/lib64/python2.7/site-packages/as
   tropy/coordinates/angle_lextab.py'
   WARNING: Couldn't create u'angle_parsetab'. [Errno 13] Permission denied: u'/usr/lib64/python2.7/site-packages/astropy/coord
   inates/angle_parsetab.py'
   

   An extra issue is that this is an example from the docs, yet we didn't see this either on travis or locally. My hypothesis is that because we always run the whole test suite, and by the time the test got to this example somehow it's happy with the parsing table shipped with the install.

   @eteq - What about getting a #5563 like workaround in for all the generated tables in for 1.3.1, unless someone figures this issue out by then? I can open a PR tomorrow for it.
6. bsipocz commented on Dec 29, 2016

   

   bsipocz

   on Dec 29, 2016

   Member

   More actions

   However it was just confirmed that the previous traceback was produced with v1.2.1
7. saimn commented on Jan 23, 2017

   

   saimn

   on Jan 23, 2017

   Contributor

   More actions

   I noticed by the past that these files appeared as modified in git but didn't pay attention to it. Now following #5726, I still can reproduce the issue on Python 2:

   ~/lib/astropy master* conseil@musicos1
   ❯ git status
   On branch master
   Your branch is up-to-date with 'origin/master'.
   nothing to commit, working directory clean
   
   ~/lib/astropy master* conseil@musicos1
   ❯ python -c "from astropy import units as u; from astropy.coordinates import SkyCoord; c = SkyCoord('00:42.5 +41:12', unit=(u.hourangle, u.deg))"
   
   ~/lib/astropy master* conseil@musicos1
   ❯ git status
   On branch master
   Your branch is up-to-date with 'origin/master'.
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git checkout -- <file>..." to discard changes in working directory)
   
           modified:   astropy/coordinates/angle_lextab.py
           modified:   astropy/coordinates/angle_parsetab.py
   
   no changes added to commit (use "git add" and/or "git commit -a")
   
8. saimn

   added a commit that references this issue on Jan 23, 2017

   Prevent PLY to overwrite its generated files.

   ...

   60550b0
9. mhvk commented on Jan 25, 2017

   

   mhvk

   on Jan 25, 2017

   Contributor

   More actions

   fixed by #5728
10. mhvk

    closed this as completedon Jan 25, 2017