Ticket #13985 (closed defect: fixed)
Fix doctests that want write access to $HOME
| Reported by: | jdemeyer | Owned by: | tbd |
|---|---|---|---|
| Priority: | major | Milestone: | sage-5.7 |
| Component: | packages: standard | Keywords: | |
| Cc: | fbissey | Work issues: | |
| Report Upstream: | Fixed upstream, but not in a stable release. | Reviewers: | François Bissey |
| Authors: | Jeroen Demeyer | Merged in: | sage-5.7.beta1 |
| Dependencies: | #13992 | Stopgaps: |
Description (last modified by jdemeyer) (diff)
In order to make Sage as self-contained as possible, it would be good if Sage would run assuming write access only to $TMPDIR (/tmp by default) and $DOT_SAGE (~/.sage by default).
In #5155 we already fixed write access to $SAGE_ROOT, the only remaining problem is SciPy which wants to write to $HOME/.python27_compiled.
upstream: http://projects.scipy.org/scipy/ticket/1821
spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/scipy-0.11.0.p0.spkg
Attachments
Change History
Changed 5 months ago by jdemeyer
-
attachment
scipy-0.11.0.p0.diff
added
comment:4 follow-ups: ↓ 5 ↓ 6 Changed 5 months ago by fbissey
Not using sage_fortran anymore is good. i am asuming that we have set all the fortran variables either in prereq or the gcc spkg, correct? This is very important for scipy (which will test for any fortran compiler that it knows off including the ones broken because they don't have a license). Is weave the only file to want access to .pythonxx_compiled? Sounds like an upstream bug to me in any case. I'll give this a closer look from something else than an iPad before approving.
comment:5 in reply to: ↑ 4 Changed 5 months ago by jdemeyer
Replying to fbissey:
Is weave the only file to want access to .pythonxx_compiled?
Yes.
Sounds like an upstream bug to me in any case.
Agreed.
comment:6 in reply to: ↑ 4 Changed 5 months ago by jdemeyer
Replying to fbissey:
I am asuming that we have set all the fortran variables either in prereq or the gcc spkg, correct?
Not quite. If the GCC spkg is installed, then yes, we force the use of Sage's gfortran. If it's not installed, we don't set any variables and let scipy figure it out. That sounds reasonable and in any case seems to work fine for the R spkg.
comment:7 Changed 5 months ago by jdemeyer
- Description modified (diff)
- Report Upstream changed from N/A to Reported upstream. No feedback yet.
comment:8 Changed 5 months ago by jdemeyer
- Dependencies set to #13992
The Fortran stuff has problems indeed, it seems that SCons does The Wrong Thing on OpenSolaris (which just proves my point again that SCons is utter crap compared to an autotools-based system, R for example compiles Fortran code just fine).
comment:9 Changed 5 months ago by fbissey
It would be easy to make this ticket a !SCons bashing exercise (I am sure your expressed opinion is watered down compared to your real one and I would be agreeing to the non-watered down too).
comment:10 Changed 5 months ago by jdemeyer
- Report Upstream changed from Reported upstream. No feedback yet. to Reported upstream. Developers acknowledge bug.
comment:11 Changed 5 months ago by jdemeyer
François: any chance you can review this, now that the Fortran problem is solved?
comment:12 Changed 5 months ago by fbissey
- Status changed from needs_review to positive_review
- Reviewers set to François Bissey
Since upstream has approved the patch and all the other issues have been dealt with, I am reviewing this positive. I was going to do test builds but you do more of these than me :)
comment:13 Changed 5 months ago by jdemeyer
- Status changed from positive_review to closed
- Resolution set to fixed
- Merged in set to sage-5.7.beta1
comment:14 Changed 4 months ago by jdemeyer
- Report Upstream changed from Reported upstream. Developers acknowledge bug. to Fixed upstream, but not in a stable release.

Diff for the SciPy? spkg, for review only