Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#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 Erocal, Mike Hansen, Jeroen Demeyer 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:

Status badges

Description (last modified by flint)

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)

nb_style_environ_variable.patch (946 bytes) - added by flint 12 years ago.
sets up new environment variable for location of notebook style files

Download all attachments as: .zip

Change History (13)

Changed 12 years ago by flint

sets up new environment variable for location of notebook style files

comment:1 Changed 12 years ago by flint

Description: modified (diff)

comment:2 Changed 12 years ago by Burcin Erocal

Authors: burcin, flintAchim Fassbender
Cc: Burcin Erocal added
Status: newneeds_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 11 years ago by Radoslav Kirov

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 11 years ago by Radoslav Kirov

Keywords: sd31 added
Status: needs_infoneeds_review

comment:5 Changed 11 years ago by Burcin Erocal

Authors: Achim FassbenderAchim Fassbender, Rado Kirov
Cc: Mike Hansen Jeroen Demeyer added
Reviewers: Burcin Erocal
Status: needs_reviewpositive_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 11 years ago by Jeroen Demeyer

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 11 years ago by Jeroen Demeyer

Milestone: sage-4.7.1sage-4.7.2

*ping*

how should the flask notebook be merged?

comment:8 Changed 11 years ago by Radoslav Kirov

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 ; Changed 11 years ago by Jeroen Demeyer

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 11 years ago by Radoslav Kirov

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 11 years ago by Jeroen Demeyer

Merged in: sage-4.7.2.alpha1
Resolution: fixed
Status: positive_reviewclosed

comment:12 Changed 11 years ago by Jeroen Demeyer

Authors: Achim Fassbender, Rado KirovAchim Fassbender, Radoslav Kirov
Note: See TracTickets for help on using tickets.