I’m author of this extension. I’ve followed the migration guide and successfully tested the extension locally on JupyterLab 3.0.
Now, I decided to move to the federated extension distribution where user needs to only install python package which would include JS for the frontend part as well (user doesn’t need to deal with installing npm packages). Please let me know if I misunderstood the federated distribution.
I built the extension using python -m build and it seems like JS / TS is included in the wheel here. But when I install the package in fresh JupyterLab 3.0 environment the extension is somehow not activated. I tried enabling/activating extension but nothing works. Any help is appreciated!
1 Like
Here’s the screenshot of JupyterLab console logs when I install the extension package in a fresh environment for testing. As you can see, our extension jupyterlab_gitplus is linked & loaded correctly.
I wonder what does the 1st statement mean - Consider moving the extension to Jupyter Server's extension paths.
That’s great, porting to federated gives a great user experience 
The compiled federated extensions need to be placed in share/jupyter/labextensions/ by installer (which is a distinct location from where the server extensions go; the warning you are getting is about notebook/server extension and is not relevant to the federated extensions system).
Have a detailed look at setup.py in GitHub - jupyterlab/extension-cookiecutter-ts: A cookiecutter recipe for JupyterLab extensions in Typescript and the overall organization of the cookiecutter. Happy to answer questions once you get a bit better feel about it.
1 Like
Thank you @krassowski
For now, I’ve decided to stick to the old distribution mechanism,
- For backwards compatibility with JL 2.0
- JL 3.0 extensions manager does not recognise federated extensions yet it seems
Thanks for your help though. From your comment, I understood that I needed to change my setup.py to build the package in a certain format for it to be federated capable. The cookiecutter migration utility did ask whether I needed to change my setup.py but I chose No at the time 
That utlity is very agreesive, it asked whether I want to modify handler.py, index.ts & so on (all the important files). Honestly, I didn’t trust that utility to modify these files correctly (as in merge it’s changes properly with my current changes). But looks like I will need to manually port over some changes into setup.py whenever I decide to move to federated distrbution (which is okay).
My strategy for porting extensions over is to use the cookiecutter to generate an example extension, then manually copy over the logic to the new extension framework, i.e., basically do that migration by hand. For me, it’s more understandable and predictable, and it doesn’t take too much time at all.
2 Likes
Yeah that’s a good strategy @jasongrout
Aside (as we’ve a distinguished contributor & steering council member on this thread ) -
With all the improvements for extension development in JL3.0, I seriously hope that we’re at stable point in extension development & distribution mechanism going forward. With each new non-backwards compatible improvement the ecosystem gets fragmented in multiple ways (both for users & developers). Feels like the notebook format & messaging protocol has thrived on the back of years of stability & backwards compatible changes, but the actual client IDE & extension ecosystem is a different story.
Of course you all know this much better than I do & there are probably some difficult trade-offs you had to make along the way (radical improvement vs. backwards compatibility). I just wanted to share my thoughts based on my limited perspective if that helps in future direction.
It sounds like you have a good grasp of the tradeoffs. Believe me, we feel that pain of porting things over acutely too. I have hopes that the distribution mechanism is settling down with the prebuilt extension system being proved out, and I don’t see a huge disruptive change in the distribution mechanism looming on the horizon.
Aside from the distribution mechanism, individual component APIs continue to evolve, especially with the introduction of real-time collaboration, the rewrite of the file browser, standardizing on CodeMirror as the editor, etc. Some exciting things are planned for 4.0, which unfortunately means that some APIs will not be backwards compatible in the major release, but as you say, such is the price of progress. We do what we can to ease the burden, though, and we are working on trying to have a predictable cadence so people can plan around a release.
2 Likes
