-
Notifications
You must be signed in to change notification settings - Fork 148
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
Orbiting closer to the Jupyter? #238
Comments
An alternative would be setting up a dedicated organisation, as we may want to have more than one repository later on. However, even an independent GitHub org can be either under JupyterLab, or Jupyter governance or neither, which would be good to discuss. |
Agreed, a repo change would suggest some more serious intent. There is
precedent for long-lived branches on lab itself, but incubator would be a
fine choice. I think there's a repo where we can ask for a spot.
Just some thoughts:
Wherever it is, we probably need a clean fork into the lab 2.x line. It
would be _possible_ to preserve history (but not tags). We'd probably have
to toss the robot tests, and use puppeteer, and adapt a bunch of other
things (docs, etc). Also, I don't know whether the r stack belongs in lab
core: we're going to do some damage to ci performance as it is.
…On Fri, Apr 3, 2020, 15:37 Michał Krassowski ***@***.***> wrote:
An alternative would be setting up a dedicated organisation, as we may
want to have more than one repository later on. However, even an
independent GitHub org can be either under JupyterLab, or Jupyter
governance or neither, which would be good to discuss.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/krassowski/jupyterlab-lsp/issues/238#issuecomment-608622435>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALCRBPFMFBFRAN4IQCIDTRKY3JDANCNFSM4L4LQ3MA>
.
|
Great! To clarify/stress, I am not thinking about getting into the core just yet, so I hope that we would not need to sacrifice any of the robot testing/CI/R stack. I am thinking more about the jupyterlab/toc or jupyterlab/debugger level of closeness. In the long run, R stuff would probably be best served from a separate repo (but again, for me, utility beats purity here) |
@krassowski Based on jupyterlab/frontends-team-compass#67, let's put together the pre-proposal for doing a JEP to get an official-ish org. Do you want to coordinate a half hour or so to hack something up? I've got a curiously low-stress week, so can accommodate whatever time works for you. We have a pretty cool binder setup with hot branches of jupyter-videochat, jupyter-drawio, #278, and some other doodads, if you want to try that out. |
Or, if you want to hit it more asynchronously, here's my draft: https://gist.github.com/bollwyvl/c3c4d71ba4f477bdd258e62c93aedb70 Fork and destroy! |
It is certainly a very good start, thank you! I'm happy to take a closer look next week (after Tuesday) |
Great, no rush of course! I think the mean time to get one of these things through is a few months ;P I'll be checking out the other flurry of work, and have started making overtures to the robot language server guys to get that into fighting shape so we can start using it. |
Hi @bollwyvl, I feel it is a good time now to move with the JEP. The codebase is far from perfect, but we now have a reasonably good coverage with the acceptance tests. I use the LSP extension as a daily driver and can confirm that it works well most of the time. We now support all three namesake big ones: Julia, Python and R. I updated the pre-proposal and would like to proceed with submitting after hearing back from you: https://gist.github.com/krassowski/cc4d827c55dfd536b60da3bf309be1b9 |
All your suggestions were great! I opened jupyter/enhancement-proposals#67. |
Cool. How do we want to go about preparing the actual JEP document? The gist-fork-tag didn't seem that bad, while hackmd would be good if we ever wanted to weld together a time to sync up on it (works fine mostly async, as well). |
gist is fine, but hackmd seems even better! |
Well, here's a totally empty one of the template https://hackmd.io/@ZwtCtWOtRGGaYNxshdBTHA/B1X9bU2kd/edit And see if you like working there... Presumably, there's some way we can use something out-of-band like gitter to hand around the URL of a follow-on doc. I'm not much of a hackpad wiz! I have a few collected thoughts in some older stuff (actually, a few) but I think they changed the format. Anyhow, would you be more inclined to:
Open to whatever, I just don't want us to spend a lot of re-work on it! |
I had another pass on the hackmd, and it starts to get in shape. I will leave it there for the week, and then open a PR here in this repo for all interested contributors to review (for two weeks) so we can polish it before opening a PR on the JEP repo, so that we can open the PR for a JEP before the end of June. |
The JEP is now open: jupyter/enhancement-proposals#72 |
JEP is now accepted. Closing from new organization 🎉 |
I would like to start thinking about moving this repo into one of the Jupyter organisations. I am not sure if JupyterLab will accept us as this project is still huge WIP*, but there is a concept of an incubator (https://github.com/jupyter-incubator) and I think that we might be a good fit there.
Important information about contributing extensions is in:
@bollwyvl, I would like to hear your thoughts on this first and only then open any discussion in the team-compass. Given that we both were aiming at getting this closer to the core and strived to keep Jupyter standards the only thing that would IMO change is the branding (and maybe - just maybe - we would be able to attract more contributions).
*) but compared to juptyerlab-monaco and some other repos out there, jupyterlab-lsp actually works ;)
The text was updated successfully, but these errors were encountered: