[wip] add kernels page #7
Conversation
|
Yes, I agree with all of the motivational points! Some other comments:
|
|
👍 Love this direction, thanks for taking the time to do it. I'm a bit lost on what the colors mean here:
This will sound petty but I don't think we should show BrainFuck in the list (either that or censor out the F word). |
|
Wnated to get some stuff out before 👶.
Hadn't done a hierarchical feature, but sounds reasonable. I think "which magics" is a valid, question, but maybe buried under a link, or on a kernel-specific page.
Yeah, we're going to need some Github integration... otherwise this becomes a maintenance nightmare. I really don't want to be running another server for this, so client-side API calls might be the best way, but I am open to suggestion.
Added. Updated and popularity are another story. I really think we'll have to go to pulling this off a repo (i.e. most recent tag), as I really don't want people to have to dink with this every day.
Sorry, left this in without meaning to before cleaning it up some more. Related to the discussion of automated kernel feature tests, I want to visually depict for a given kernel/feature:
Removed. This, for example, would never have passed the PR process! |
|
This is great! I probably wouldn't include 'magics' on the index at all. It's not something that anything in Jupyter is aware of. I think the only way it's meaningful is as a bool indicating 'extends the language syntax in some way', which I'm not sure is the most useful. |
| @@ -0,0 +1,3 @@ | |||
| [submodule "bower_components"] | |||
There was a problem hiding this comment.
oof, do we have to use a submodule? I was so happy to get rid of our submodule in the notebook.
There was a problem hiding this comment.
As i mentioned, I'd prefer a build step from another branch that built master, and the bower components would be checked in there. However, due to how github pages works, the submodule is for my sanity right now so that there is always a working demo.
There was a problem hiding this comment.
Sounds good, thanks for the explanation. I'll try to read more carefully.
|
I would also remove the parallel computing piece as a feature mark. IPython.parallel is not planned to be extended to other Jupyter kernels. |
|
@minrk I disagree about not listing magics... I think these can be an important component of a Jupyter kernel. It may be that a language has a method of performing such functionality, but to bring them out of the language and create a standard API is something that is quite useful. And I see some very clever magic systems being developed (for example, some Javascript-based magics). I also see some that I'd love to see IPython adopt. Seeing that you just added parallel to the suggestions of removing... I also disagree with the removal of that. There are a few kernels that implement parallel processing, and that can be an important feature. |
|
I agree that BrainF@#k should be sanitized. I think it would be perfectly fine to use a better/different name. I have use This does suggest just a couple of rules: no offensive or sexist language; probably a standard "code of conduct" statement should be linked to: |
|
I see your point about magics. If 'magic' is defined as 'extends the language in any way', a link to a URL explaining what a kernel adds to the respective language is appropriate. I would actually avoid the use of the term 'magics' in that case, though. That's what IPython happens to call its extensions to Python, but I think it indicates an intent to standardize language extensions across languages that we do not have. I think including parallel computing is confusing, though. Going forward, for instance, the IPython kernel itself won't provide any parallel computing. A separate, derivative project called 'IPython parallel' does. |
|
And almost all serious languages have some kind of functionality for parallelism, which you should be able to use from a Jupyter kernel for that language. The only particular integration with Jupyter, as far as I know, is the support for starting and stopping clusters using IPython parallel - and we should probably aim to justify that. |
|
@takluyver I've thought about that, too, and I think we should remove the clusters panel from the notebook, and move it to IPython parallel as an nbserver extension. |
|
Wow, thanks for all the feedback! Some good soul searching happening here. I've made features into a filter, and added tooltips, but have downplayed them by removing the colors and moving them below the description. Also removed the offending parallel feature, and renamed "magic" to "language extension". I guess the best way to add "this is tested" is as an action (like docker, github or try.j.o), calling out to travis. Additionally, I've tightened up the copy a bit, and would consider most of that no longer FPO: any additional insight welcome. Finally, design: I've removed as many lines/borders as I could, hopefully this doesn't make it unclear what can be clicked. Now, really only the kernels themselves get a border, which seems like a good choice. remaining tasks:
remaining questions:
|
|
I've tried added bootstrap material design! Obviously, we'll want to do a bit of color work, but I like what it does out of the box. Also more copy changes etc. |
Nice! |
Yep... btw... I see the logo and Kernel at the top and I like the idea to have it there, but I think they have to be centered. Not left-aligned. Also, I think the cards is a better default than cells or list... |
|
Do you want to list every implementation of an IPython kernel that there is around there (even the most hacky ones?) |
|
I think we need to have some way of indicating quality. As @minrk mentioned the other week, though, it's probably tricky to do that with a manually maintained whitelist, because it's always going to be contentious for things that fall near the line. I'm thinking more along the lines of an automatically calculated score, which could be based on things like Github stars, results of automatic testing, possibly download counts (though they're probably hard to compare for different kernels). |
|
Sorry, I haven't touched this in a while. Yeah, the original proposal on the linked issue included automated tests, Scores are tough, and can be gamed... not super worried about that. Perhaps the good ol TRL scale: Each has a type of information needed, from, say a gist up to membership in On Tue, Jun 16, 2015 at 1:55 PM Thomas Kluyver notifications@github.com
|
|
Closing here to to keep a small number of PR openend that are actually worked on Thanks ! |
|
Agree with the queue gardening intent, and it would take a bit of work to rebase, but I still feel strongly about having a data-driven listing of (initially) kernels, and would be happy to work on this, especially with some guidance on the presentation! I think prior to re-proposing this, we would need to figure out the build story... I'll go create a ticket! |
|
I certainly still want a kernel listing. |
Problem
Using the kernels wiki page is very manual, not very compelling, and liable to get spammed at some point.
Proposed
This adds a curated, data-driven kernel page to jupyter.org, as requested from here.
Feedback welcome! Let's make something really great!
Data Model
Because of the interconnected, extensible nature of what we are trying to represent (kernels, features, language versions, actions for a kernel project, etc.) the data in
kernels.jsonis captured as JSON-LD, which is just JSON, but every key means an URI, and some values are treated as URIs. I am not actually using jsonld.js yet, anyway.I would be open to being convinced of not thinking about this data this way, but I'll fight you for it!
Content
I pulled what I could from the wiki page, but there is definitely going to be some data collection effort! However, it should really be a one-time big push, and could likely be crowdsourced with a google spreadsheet. Future changes would become the responsibility of the kernel authors!
Everything is in one file, which obviously doesn't need to be that way, but for the time being it was easy. Eventually, things like the specific features implemented should be created in a reproducible manner, as discussed here, and as such would live in a separate file.
Libraries
Because of the data-driven angle, I have used d3. It's a bit overkill for what is currently being done, i.e. the page could be pre-generated by Jekyll, and search implemented more simply, but it helps me build quickly while staying true to the data.
I am open to suggestion of some other framework (considered backbone initially), but I think d3 actually fits the bill pretty nicely. It's not commented very well either, which I will fix at some point.
CDN vs Bower
I have moved away from relying on CDN to bower... mostly for my sanity coding with spotty connectivity. If we're serious about performance, we should eventually do a build of CSS and JS, as one or two big files is almost always going to be a better optimization. The bower components are submoduled in at present... I imagine eventually that they would live right in
master, and that we would build from separate branch... potentially deployed via travis, but I haven't set this up before.Visual Design
I haven't strayed much from the bootstrap baseline, so it should be easy to add a bootstrap theme. Obviously, this would best be done site-wide. Here are some I liked:
...but really anything other than vanilla bootstrap, 🙏.