#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 | Merged in: | sage-5.7.beta1 |
Authors: | Jeroen Demeyer | Reviewers: | François Bissey |
Report Upstream: | Fixed upstream, but not in a stable release. | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #13992 | Stopgaps: |
Description (last modified by )
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 (1)
Change History (15)
Changed 8 years ago by
comment:1 Changed 8 years ago by
- Description modified (diff)
comment:2 Changed 8 years ago by
- Status changed from new to needs_review
comment:3 Changed 8 years ago by
- Cc fbissey added
comment:4 follow-ups: ↓ 5 ↓ 6 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
- Description modified (diff)
- Report Upstream changed from N/A to Reported upstream. No feedback yet.
comment:8 Changed 8 years ago by
- 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 8 years ago by
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 8 years ago by
- Report Upstream changed from Reported upstream. No feedback yet. to Reported upstream. Developers acknowledge bug.
comment:11 Changed 8 years ago by
François: any chance you can review this, now that the Fortran problem is solved?
comment:12 Changed 8 years ago by
- Reviewers set to François Bissey
- Status changed from needs_review to positive_review
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 8 years ago by
- Merged in set to sage-5.7.beta1
- Resolution set to fixed
- Status changed from positive_review to closed
comment:14 Changed 8 years ago by
- 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