Michał Krassowski krassowski

JupyterLab 4 on Binder

JupyterLab 3.2.9 on Binder

Features

Real Time Collaboration enabled

Pre-Proposal Checklist

Briefly outlines the proposal
Suggests a review team (optional)
Declares why it should be a JEP (See the “JEP / Not-a-JEP Rubric” below.)
Identify a Shepherd to see the process through. (Shepherds are assigned on a round-robin basis from a set of interested engaged volunteers).
Decide if it’s a JEP according to the criteria listed above. The Shepherd decides if the JEP criteria have been met.

Pre-Proposal

The maintainers of the jupyter(lab)-lsp would like to propose its incorporation as an official Project Jupyter project, as signalled by a new, Jupyter-branded GitHub organization. We feel it would benefit Jupyter users through higher velocity in delivering more robust features otherwise missing in the Jupyter interactive computing experience.

What is a kernel?

The kernel lets you run code in a particular programming language using one of the Jupyter tools, such as the Notebook, Jupyterlab or nteract. Installing additional kernels will let you run code in more languages using your existing jupyter installation.

Technically, the kernel is an application which speaks the Jupyter Messaging Protocol, to receive code input from the frontend and respond with the results.

Which kernels do I have installed?

In the Notebook or JupyterLab, the list of available kernels will be shown when trying to create a new notebook.

If you are like me you find yourself cloning a repo, making some proposed changes and then deciding to later contributing back using the GitHub Flow convention. Below is a set of instructions I've developed for myself on how to deal with this scenario and an explanation of why it matters based on jagregory's gist.

To follow GitHub flow you should really have created a fork initially as a public representation of the forked repository and the clone that instead. My understanding is that the typical setup would have your local repository pointing to your fork as origin and the original forked repository as upstream so that you can use these keywords in other git commands.

Clone some repo (you've probably already done this step)
```
git clone [email protected]
```

	from pandas import DataFrame, ExcelWriter, Series


	# assuming you have tables:
	participants_sumnary = DataFrame()
	measured_things = DataFrame()
	correlation_results = DataFrame()
	model_results = DataFrame()

	# To Setup:
	# 1) Save the .git-completion.bash file found here:
	# https://github.com/git/git/blob/master/contrib/completion/git-completion.bash
	# 2) Add the following lines to your .bash_profile, be sure to reload (for example: source ~/.bash_profile) for the changes to take effect:

	# Git branch bash completion
	if [ -f ~/.git-completion.bash ]; then
	. ~/.git-completion.bash

	# Add git completion to aliases

	So you've cloned somebody's repo from github, but now you want to fork it and contribute back. Never fear!

	Technically, when you fork "origin" should be your fork and "upstream" should be the project you forked; however, if you're willing to break this convention then it's easy.

	* Off the top of my head *

	1. Fork their repo on Github
	2. In your local, add a new remote to your fork; then fetch it, and push your changes up to it

	git remote add my-fork [email protected]