Skip to content
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

Update the recommended JupyterLab version #276

Merged
merged 14 commits into from
Jul 19, 2020

Conversation

krassowski
Copy link
Member

@krassowski krassowski commented Jun 7, 2020

References

Follow-up after #275. Closes #289.

Code changes

  • source of truth for JupyterLab version is now taken from packages, not from binder environment
  • versions.py added to the root to ensure versions consistency across the repo
  • Installation notebook now uses code cells with modified markdown magic to display the variables

User-facing changes

None

Backwards-incompatible changes

None

Chores

  • linted
  • documented

@bollwyvl
Copy link
Collaborator

bollwyvl commented Jun 8, 2020

sorry the version appears in so many places, looks like just readme and the lab.txt are
out of sync.

👍 to requiring lab 2.1, though!

@krassowski
Copy link
Member Author

Would you think that converting the markdown cell in docs/Installation.ipynb to a code cell returning a markdown object, then hiding the code and only displaying the result would be possible/advisable? This would allow to having the versions from variables...

@bollwyvl
Copy link
Collaborator

Yeah, we could parse job.test.yml and pull out the "broadest" spec. Though looks like right now they are all set to >2,<3.0.0a0.

I think we have some other examples of using nbsphinx: source_hidden in some of the other notebooks... it's buried down the the metadata -> advanced sidebar in cell metadata.

@krassowski
Copy link
Member Author

I think I found an elegant solution: spatialaudio/nbsphinx#81 (comment) :)

@krassowski
Copy link
Member Author

So this still WIP, but 43a08ce is POC that it works. Just need to bump the JupyterLab version in the npm package and decide where to put the version and markdown cell code (which currently is in the notebook, but it certainly should go somewhere).

@krassowski
Copy link
Member Author

I added versions.py in the root of the repo to track versions more reliably, with a single source of truth across the repo. CI now passes - apart from Windows being Windows.

@krassowski krassowski closed this Jul 19, 2020
@krassowski krassowski reopened this Jul 19, 2020
@bollwyvl
Copy link
Collaborator

Now that all this (almost) works: I thought there were things (related to completion #239?) we definitely wanted from Lab 2.2.0... how might we validate that the features in question landed?

@krassowski
Copy link
Member Author

This is a good question. I asked in the jupyterlab/jupyterlab#8080. There was also jupyterlab/jupyterlab#8375, none of which is in the final changelog. But then, the 2.2 release was a bit unusual...

@bollwyvl
Copy link
Collaborator

Hooray green CI! It seems like merging now, and doing the release dance, would make sense as 2.2.0 is not widely distributed. Then do the next release with the hard 2.2.0 dependency.

@krassowski
Copy link
Member Author

Looks like it - thanks for checking! So my current plan is to:

Not sure where #288 would fit.

@krassowski krassowski merged commit b93f102 into master Jul 19, 2020
krassowski added a commit that referenced this pull request Jul 19, 2020
@bollwyvl
Copy link
Collaborator

merge #278

I'm super excited that you are interested in #278: we've been demoing with it on https://github.com/deathbeds/_fam/tree/07-11-2020 and it's been working pretty well. I've also been tinkering with a JEP to formalize the schema it uses.

Not sure where #288 would fit.

Let's not hold up anything for #288: it is, however, pretty important to some other stuff I'm working on (and getting paid for) so it will get finished, at some point. Presently, I'm still having issues getting it built on OSX, which is very hard to debug from a distance, but it won't actually have that big of an impact once it lands (would just be a small dot release of the server piece). Really getting it to work, though, will require a dedicated extension:

@krassowski krassowski deleted the krassowski-update-docs-versions branch September 4, 2020 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Installation docs show two diff versions of jupyterlab
2 participants