-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hardwired path to jupytergraffiti_data #21
Comments
Thank you for the suggestion! What I'm thinking is that when you Activate Graffiti on a notebook, you can enter an (optional) e.g.
That is, unless you meant a different path for every single graffiti? This wouldn't work because every notebook has its own single manifest file, containing information about all the graffiti in the notebook. |
Hi Re: diffferent paths, I was meaning the notebook level. So eg I might have:
with all the graffiti stuff in the common, hidden directory? Providing a path via notebook metadata would be handy (notebook arguably needs a more streamlined metadata editing route I think?). With all the metadata, I'm wondering if/how jupytergraffiti will work with things like |
^^ seems quite doable. Note that you are asking that the directory name for the data is also specified... ie, you want to be able to say something like:
... and it would not use Not sure about jupytext, don't have much familiarity with it. If it leaves graffiti metadata at the notebook and the cell level alone, then things should work except for the graffiti added to markdown cells. These are positioned by placing html tags around the text involved. If jupytext should strip these then you'd lose access to the graffiti. (In code cells, the positions of the graffiti are kept via token tracking, not by modifying the code cell contents directly, so that should make it through). Perhaps you can give jupytext a try and see what transpires? |
I will give it a go when I get a chance - next week probably... gonna be
away from m/cs for a few days...
…On Thu, 25 Apr 2019 at 18:37, Will Kessler ***@***.***> wrote:
.graffitibits/
week1/
nbactivity1.ipynb
nbactivitiy2.ipynb
week2/
nbactivity3.ipynb```
Seems quite doable.
Not sure about jupytext, don't have much familiarity with it. If it leaves
graffiti metadata at the notebook and the cell level alone, then things
should work *except* for the graffiti added to markdown cells. These are
positioned by placing html tags around the text involved. If jupytext
should strip these then you'd lose access to the graffiti. (In code cells,
the positions of the graffiti are kept via token tracking, not by modifying
the code cell contents directly, so that should make it through).
Perhaps you can give jupytext a try and see what transpires?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#21 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAUILE6DZGMZM4UT5Q3TH3PSHT7JANCNFSM4HIMHABA>
.
|
Sounds good, we should have the customizable data path ready before you get back :-) |
Turns out we cannot use a hidden directory because Jupyter will not serve content from hidden directories for security reasons (jupyter/notebook#2382 (comment)). However, you can name the folder with some prefix like |
@psychemedia You can now change the data path. If you pull the latest version of the repo, you will now find the Graffiti Editor panel has a button for changing the data path and folder. It looks like this: When you click the icon, you will then be prompted to specify a data path as shown here: You can specify a relative path vis-a-vis your notebook's location. Note:
|
I notice that you're using a hardwired path to
jupytergraffiti_data
here.It would be useful if this path could be set by the jupytergraffiti screencast creator (eg they might want to specify a hidden directory or a common directory referenced from several directories containing their own graffitied notebooks), perhaps via a metadata editor / panel reached from / on the graffiti control panel?
A guard to check the existence of, and create otherwise, the directory would probably also make sense?
The text was updated successfully, but these errors were encountered: