This means we can now dynamically load extensions without the need for a build. This functionality allows for a JavaScript application to ship and load JavaScript modules on demand without having to pack it in the initial application bundle (a different Webpack build). So, how did this come to be? Well, this could not have been achieved without advancements in WebPack version 5, the JavaScript library in charge of “bundling JavaScript files for usage in a browser” and the new module federation functionality. In JupyterLab 3, all of the packaging will be orchestrated by using pip, relying on PyPI alone. Fortunately, we have Conda to help with some of these concerns but users still need Node.js and Python environments to reap the benefits. Users would have to install these packages from combinations of npm and PyPI packages. A common problem in JupyterLab versions 1 and 2 was handling extensions. They said the browser was the future! This meant that already complicated installation and packaging issues became more complicated. A familiar toolchain for PythonĪt some point, the Jupyter Python community got very wrapped up in JavaScript development. In JupyterLab 3, users will experience reduced installation times, and Python users will rely on a familiar installation pattern by using pip. This improvement applies broadly to the JupyterLab ecosystem because all of the components are extensions! This had to be performed every time a new extension was installed! In JupyterLab 3, an extension developer will package the JavaScript or CSS and ship that through PyPI with the prebuilt codes. Currently, JupyterLab users are required to have a Node.js run-time in their environment in order to build and install JupyterLab extensions (written in TypeScript/JavaScript and providing different assets). User impacts of version 3Īs long-time Jupyter super users, the new changes to distributing JupyterLab extensions are particularly exciting. Version 3 upgrades will save y’all’s and organization’s time and improve the quality of collaborative work. The development during this phase proved the extensibility of JupyterLab and its ability to serve as a foundation for creating custom interactive computing interfaces this foundation allows it to fit the needs of different users, disciplines, and workflows. These connections are possible only because JupyterLab connected modern, performant JavaScript with scientific computing interfaces that improved users’ abilities to communicate and collaborate. There are now extensions for interacting with big data (e.g., Dask, HoloViz ), collaborating with others (e.g., jupyter-videochat ), and customizing styling. During its time, the extensions ecosystem flourished. JupyterLab version 2 was a landmark in the interactive computing development phase. The next few sections will highlight the impacts of this upgrade from individual and organizational perspectives. Very soon, JupyterLab will be achieving a major milestone by upgrading from version 2 to 3. This model allows for development to happen inside the tool itself, and co-development to happen by the surrounding ecosystem. Third-party community extensions can then be installed to enhance and augment the user experience. The core extensions that ship with JupyterLab that establish the baseline JupyterLab interface. The extension system is a central concept to JupyterLab all of the features (e.g., notebook editor, file browser, menus, and status bar elements) are extensions that interface into the greater JupyterLab ecosystem.
We discussed the toil that core developers are investing to improve the experience of JupyterLab not only for developers but for users as well. During a recent quirkshop our incredible JupyterLab developers got together to discuss the upcoming major version changes to JupyterLab. Quansight, we’ve been hosting a series of live streams that feature our talented open source developers talking about the software they contribute to and the communities around them.
0 kommentar(er)
