#11106 closed enhancement (fixed)
Make location of notebook style files configurable
Reported by: | flint | Owned by: | jason, mpatel, was |
---|---|---|---|
Priority: | minor | Milestone: | sage-4.7.2 |
Component: | notebook | Keywords: | notebook, style, sd31 |
Cc: | burcin, mhansen, jdemeyer | Merged in: | sage-4.7.2.alpha1 |
Authors: | Achim Fassbender, Radoslav Kirov | Reviewers: | Burcin Erocal |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
Developers working on the customization of the notebook style for a site installation might wish to easily switch between different styles. The patch offered here adds the following functionality to sage notebook: If the environment variable SAGENB_TEMPLATE_PATH is defined then its value is taken as the location the style files are loaded from. Otherwise they are loaded from a default location as before.
Attachments (1)
Change History (13)
Changed 10 years ago by
comment:1 Changed 10 years ago by
- Description modified (diff)
comment:2 Changed 10 years ago by
- Cc burcin added
- Status changed from new to needs_info
Open for discussion at:
http://groups.google.com/group/sage-notebook/t/aa8a82a2b288f8ff
I understand that there is a notebook rewrite going on, but we'd really appreciate it if there was a more official way to style a notebook server. Maybe we should look into providing a similar patch for the new flask server as well.
comment:3 Changed 10 years ago by
looks good. merged in the flask rewrite of the notebook. Added checking if the directory actually exists.
http://code.google.com/r/rkirov-flask/source/detail?r=5f1cd22d52f2e72eff065653a41cb0816cd4675f
comment:4 Changed 10 years ago by
- Keywords sd31 added
- Status changed from needs_info to needs_review
comment:5 follow-up: ↓ 6 Changed 10 years ago by
- Cc mhansen jdemeyer added
- Reviewers set to Burcin Erocal
- Status changed from needs_review to positive_review
What is the procedure to close notebook tickets? This was merged in the flask notebook, so it can be closed.
comment:6 in reply to: ↑ 5 Changed 10 years ago by
Replying to burcin:
What is the procedure to close notebook tickets? This was merged in the flask notebook, so it can be closed.
It all depends how the "flask notebook" should be merged into Sage.
comment:7 Changed 10 years ago by
- Milestone changed from sage-4.7.1 to sage-4.7.2
*ping*
how should the flask notebook be merged?
comment:8 follow-up: ↓ 9 Changed 10 years ago by
not sure if I should be answering this, but i am guessing it will become a separate spkg. Is there an obvious problem with this?
comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 10 years ago by
Replying to rkirov:
not sure if I should be answering this, but i am guessing it will become a separate spkg. Is there an obvious problem with this?
Rado, do you mean a new spkg in addition to the existing "sagenb" or will it be inside "sagenb"?
There is no problem with this but I think it is something that you really should think about. As I mentioned on http://groups.google.com/group/sage-release/browse_frm/thread/758ac9a5106f5d4f, I would like the flask notebook to be either
(a) 100% part of Sage, in which case it is simply a set of patches on Trac which should be merged in the usual way by the Sage release manager.
(b) 0% part of Sage, i.e. a completely separate project with a separate release manager and a separate bug tracker which will give me a complete spkg to be merged into Sage.
I believe that anything between these two extremes would create extra complications. Currently, option (a) holds for sagenb. I would not find it a problem if it starts out as (b) in the development phase but once it's merged it reverts back to (a), i.e. part of Sage.
Also keep in mind that a few tickets deal mostly with the Sage library but still need patches to sagenb, so maybe (a) would be a slightly better solution. Recent examples: #9976, #10052.
comment:10 in reply to: ↑ 9 Changed 10 years ago by
Replying to jdemeyer:
Replying to rkirov:
not sure if I should be answering this, but i am guessing it will become a separate spkg. Is there an obvious problem with this?
Rado, do you mean a new spkg in addition to the existing "sagenb" or will it be inside "sagenb"?
There is no problem with this but I think it is something that you really should think about. As I mentioned on http://groups.google.com/group/sage-release/browse_frm/thread/758ac9a5106f5d4f, I would like the flask notebook to be either
(a) 100% part of Sage, in which case it is simply a set of patches on Trac which should be merged in the usual way by the Sage release manager.
(b) 0% part of Sage, i.e. a completely separate project with a separate release manager and a separate bug tracker which will give me a complete spkg to be merged into Sage.
I believe that anything between these two extremes would create extra complications. Currently, option (a) holds for sagenb. I would not find it a problem if it starts out as (b) in the development phase but once it's merged it reverts back to (a), i.e. part of Sage.
Also keep in mind that a few tickets deal mostly with the Sage library but still need patches to sagenb, so maybe (a) would be a slightly better solution. Recent examples: #9976, #10052.
reply in sage-release not to pollute the ticket.
comment:11 Changed 10 years ago by
- Merged in set to sage-4.7.2.alpha1
- Resolution set to fixed
- Status changed from positive_review to closed
sets up new environment variable for location of notebook style files