#143 upgraded to Jupyter Packaging 0.9, and removed the skip_if_exists check that was used to not rebuild assets if they already exist.

This is useful when packaging for conda and was added in #121, for example to not require jupyterlab as a host dependency.

Trying with the latest cookiecutter, the following now seems to be triggering a build:

python -m pip install build
python -m build

# assets are in the tarball under `myextension/labextension`

# create a new env
mamba create -n tmp python -y

# install from source should just "copy files"
python -m pip install ./dist/myextension-0.1.0.tar.gz

Giving:

  
  Traceback (most recent call last):
    File "/tmp/pip-build-env-t8o7cw22/overlay/bin/jlpm", line 8, in <module>
      sys.exit(main())
    File "/tmp/pip-build-env-t8o7cw22/overlay/lib/python3.9/site-packages/jupyterlab/jlpmapp.py", line 43, in main
      execvp('node', ['node', YARN_PATH] + argv)
    File "/tmp/pip-build-env-t8o7cw22/overlay/lib/python3.9/site-packages/jupyterlab/jlpmapp.py", line 24, in execvp
      cmd = which(cmd)
    File "/tmp/pip-build-env-t8o7cw22/overlay/lib/python3.9/site-packages/jupyterlab_server/process.py", line 59, in which
      raise ValueError(msg)
  ValueError: Please install Node.js and npm before continuing installation. You may be able to install Node.js from your package manager, from conda, or directly from the Node.js website (https://nodejs.org).
  Traceback (most recent call last):
  
  ...

  subprocess.CalledProcessError: Command '['/tmp/pip-build-env-t8o7cw22/overlay/bin/jlpm', 'install']' returned non-zero exit status 1.
  ----------------------------------------
  ERROR: Failed building wheel for myextension
Failed to build myextension
ERROR: Could not build wheels for myextension which use PEP 517 and cannot be installed directly

Since there is a new release of JupyterLab, it would be great to upgrade the extension template.
https://github.com/jupyterlab/jupyterlab/releases/tag/v3.1.0

In the 3.0 pyproject.toml file, we specify the dependency on lab as jupyterlab~=3.0.0b6. However, this has some "interesting" matching mechanics (ref https://www.python.org/dev/peps/pep-0440/#compatible-release):

>>> import pkg_resources
>>> r = tuple(pkg_resources.parse_requirements('jupyterlab~=3.0.0b6'))[0]
>>> pkg_resources.parse_version('3.0.0') in r
 True
>>> pkg_resources.parse_version('3.0.1') in r
 False

Which means any package released with this will, in the future, always end up installing 3.0.0 final, but not any hotfixes (3.0.1).

I can do a PR to fix this, but what do we want it to do? Only match pre-releases for 3.0.0, or match any version between the specific pre-release and 4.x?

Currently in 3.0 the default build script doesn't execute the jupyter labextension build command:

Maybe jlpm run build could actually replace jlpm run build:all, so the workflow and commands would stay the same when switching to new extension system?

With the scripts updated to:

 "build": "jlpm run build:lib && jlpm run build:labextension", 
 "build:labextension": "jupyter labextension build .", 
 "build:lib": "tsc", 

See jupyter-widgets/ipywidgets@f73c36e for example.

Description

When I create a new extension with a server extension using typescript based cookiecutter in a new python environment, the example doesn't work. I don't know if I should do something in addition to build and install it.

Reproduce

I create a new python env:

conda create -n test -c conda-forge python=3.8 jupyterlab cookiecutter -y 
conda activate test

then I create a new extension using typescript cookiecutter:

cookiecutter https://github.com/jupyterlab/extension-cookiecutter-ts

with the following info:

author_name []: Author
author_email []: [email protected]
python_name [myextension]: myextension
labextension_name [myextension]: myextension
project_short_description [A JupyterLab extension.]: 
has_server_extension [n]: y
has_binder [n]: n
repository [https://github.com/github_username/myextension]: 

Then I build the extension:

cd myextension
yarn build

and install it locally for development:

jupyter labextension develop --overwrite

And finally I start jupyterlab:

jupyter lab

When a new tab is created in the browser with the lab, I see the following error in the browser's console:

JupyterLab extension myextension is activated!
myextension/get_example?1620061204704:1 Failed to load resource: the server responded with a status of 404 (Not Found)

and this one in the server console:

[W 2021-05-03 19:00:07.593 ServerApp] 404 GET /api/contents/Untitled.ipynb?content=0&1620061207590 (::1): No such file or directory: Untitled.ipynb

Is this something wrong in the example? or I am not installing the server extension correctly?

Expected behavior

I was expecting the server extension being installed after doing:

jupyter labextension develop --overwrite

and returning:

This is /myextension/get_example endpoint!

Context

• Operating System and version: macOS Big Sur 11.3
• Browser and version: Chrome 90.0.4430.93 (official build) (x86_64)
• JupyterLab version: 3.0.14

i just create a new extension project, but not very smooth.

input command "jlpm install" fail or "jupyter labextension install" fail

that my env.

nvm ls

        v15.0.1
->     v16.17.0
default -> 15.0.1 (-> v15.0.1)
node -> stable (-> v16.17.0) (default)
stable -> 16.17 (-> v16.17.0) (default)
iojs -> N/A (default)
unstable -> N/A (default)
lts/* -> lts/gallium (-> v16.17.0)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.12 (-> N/A)
lts/fermium -> v14.20.0 (-> N/A)
lts/gallium -> v16.17.0

jupyter --v

jupyter core     : 4.6.3
jupyter-notebook : 6.0.3
qtconsole        : not installed
ipython          : 7.16.1
ipykernel        : 5.3.4
jupyter client   : 6.1.7
jupyter lab      : 3.2.9
nbconvert        : 6.0.7
ipywidgets       : not installed
nbformat         : 5.0.8
traitlets        : 4.3.3

ubuntu nvidia container

NVIDIA Release 20.11-tf1 (build 17379723)
TensorFlow Version 1.15.4

i do this .
step1. change jupyter lab version, "pip install jupyterlab==3.2.9"
step2. change node version, "nvm use v16.17.0"
step3. check out 3.0 version, cookiecutter https://github.com/jupyterlab/extension-cookiecutter-ts --checkout v3.0, only this version jlpm install will be fine, but could not labextension install success package.

i just want empty page work good, a new icon page github source.

Hi,

Why do we ignore import errors here:

I raise this, as I couldn't figure out deshaw/jupyterlab-execute-time#44 for the longest time, and it turned out to be because jupyter-packaging was not installed in my release environment correctly. Instead of failing, it released.

Thanks!

Hi @jasongrout and @blink1073 : is the "ts" at the end of "extension" deliberate or is it a typo? Readme has it spelled ok. thx.

Description

This is rather a request for confirmation than a bug report.

In _version.py, fetchVersion searches package.json in the current folder (that is the folder of the python sources):

https://github.com/jupyterlab/extension-cookiecutter-ts/blob/3.0/%7B%7Bcookiecutter.python_name%7D%7D/%7B%7Bcookiecutter.python_name%7D%7D/_version.py#L7

This means the version resolution works only if the extension was built (i.e. there is a labextension folder containing the package.json in the current folder).

Is this the desired behaviour ? Would it not be more robust to search directly for package.json in the extension folder (i.e. the parent folder of the python sources) ?

At the moment on the 3.0 branch, jlpm run build will run the following:

However extension authors will want to use the browser dev tools to debug the extension, which requires running jlpm run build:labextension:dev to generate the source maps:

Maybe we could make that command the default for jlpm run build and add a new build:prod to be used by the prepare script?

(follow-up to jupyterlab/jupyterlab#8961)

Description

The repository contains a path that is invalid on Windows.

Reproduce

1. Run cookiecutter https://github.com/jupyterlab/extension-cookiecutter-ts
2. See error Command '['git', 'clone', 'https://github.com/jupyterlab/extension-cookiecutter-ts']' returned non-zero exit status 128.
3. Run git clone https://github.com/jupyterlab/extension-cookiecutter-ts
4. See error invalid path '{{cookiecutter.python_name}}/jupyter-config/nb-config/{{cookiecutter.python_name | replace('-', '_')}}.json'

Expected behavior

Context

• Operating System and version: Windows 10
• Browser and version:
• JupyterLab version:

Paste the output from running `jupyter troubleshoot` from the command line here.
You may want to sanitize the paths in the output.

Paste the output from your command line running `jupyter lab` here, use `--debug` if possible.

Paste the output from your browser Javascript console here, if applicable.

Description

Creating a new extension from scratch creates the variables.css file used for a theme:

Reproduce

Create a new extension and choose 1 (frontend).

Context

Follow-up to #196

It would be logical to have the version pulled from the package.json rather than from _version.py

The generated artifact is a python package, but having two places to define the version is not how it should be.

This has been implemented by @jtpio in jtpio/jupyterlab-python-file#19

It looks like the master and 3.0 branches have diverged quite a bit at this point, with the 3.0 branch being the main repo branch and the most recently updated.

They diverged at the 3.0 tag. Master looks like it has these PRs merged in beyond the 3.0 tag:

• #123
• #124
• #126
• #127
• #128
• #114
• #129
• #130
• #132
• #115
• #134
• #131
• #138

Since the main repo branch is 3.0, I think it makes sense to essentially merge master in (or backport from master) and get rid of the master branch.

Add localization by default but provide and option to opt-out.

As a time-saving quality of life measure for any extension author who might want their extension merged into core, or just wants more reliable code, I propose we turn this check on. This default was a bit painful when we were merging @jupyterlab/debugger into core.

/edit: I see the setup.py is pretty complex, so setuptools is probably necessary

Since JupyterLab has now switched to TypeScript 3.9, it would be nice if the extension cookiecutter would use the same version too.

We could also update the eslint dependencies at the same time.

I installed cookie cutter using conda, following https://jupyterlab.readthedocs.io/en/stable/developer/xkcd_extension_tutorial.html#xkcd-extension-tutorial
I stay in the conda software directory, ~/miniconda.
When I run this cookie cutter extension, crashes saying

FileNotFoundError: [Errno 2] No such file or directory: '/home/marian/miniconda3/myxkcd/.gitignore'

The correct answer must be PermissionsError, because this was the real original error, normal user doesn't have write privileges.

When I develop the extension and install it by:

jupyter labextension develop --overwrite .

I cannot uninstall by neither "pip uninstall" and "jupyter labextension uninstall".
When I try "jupyter labextension uninstall" it gave the error:

JupyterLab cannot uninstall jupyterlab-hide-code since it was installed outside of JupyterLab. Use the same method used to install this extension to uninstall this extension.

Hello,

When extending Jupyterlab Menu, I tumbled on an error of Set being unknown (surprising for a beginner). As the fix is simply to add ES2015.Collection in tsconfig.json. I think adding it by default in the cookiecutter template would ease the day for extension developpers.

Cheers

Description

It feels like the Binder postBuild is missing a few steps.
For an extension with server, this works to display my extension:

...

# verify the environment the extension didn't break anything
_(sys.executable, "-m", "pip", "check")

# Install the node dependencies
_("jlpm")

# build the labextension
_("jlpm", "run", "build")

# link the labextension to JupyterLab
_("jupyter", "labextension", "develop", ".", "--overwrite")

# install server
_("jupyter", "server", "extension", "enable", "jlab_aiidatree")

However, there is still a problem for me that POST requests to the server are failing (see below for full output), even though this works fine locally.

Perhaps you know a fix?

Reproduce

See binder link of https://github.com/chrisjsewell/jlab_aiidatree

Expected behavior

The extension is loaded on Binder load

Context

• Operating System and version: OSX 10.15.7
• Browser and version: Firefox 88.0.1
• JupyterLab version: 3.0

Post request failure:

Not a JSON response body. 
Response {type: "basic", url: "https://hub-binder.mybinder.ovh/user/chrisjsewell-…x5b44ro/jlab_aiidatree/querybuilder?1620960326400", redirected: false, status: 404, ok: false, …}
body: ReadableStream
bodyUsed: true
headers: Headers
__proto__: Headers
ok: false
redirected: false
status: 404
statusText: ""
type: "basic"
url: "https://hub-binder.mybinder.ovh/user/chrisjsewell-jlab_aiidatree-zx5b44ro/jlab_aiidatree/querybuilder?1620960326400"

Error on POST /jlab_aiidatree/querybuilder [object Object].
Error: <!DOCTYPE HTML>
<html>

<head>
    <meta charset="utf-8">

    <title>Jupyter Notebook</title>
    <link id="favicon" rel="shortcut icon" type="image/x-icon" href="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/base/images/favicon.ico?v=50afa725b5de8b00030139d09b38620224d4e7dba47c07ef0e86d4643f30c9bfe6bb7e1a4a1c561aa32834480909a4b6fe7cd1e17f7159330b6b5914bf45a880">
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <link rel="stylesheet" href="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/components/jquery-ui/themes/smoothness/jquery-ui.min.css?v=fb45616eef2c454960f91fcd2a04efeda84cfacccf0c5d741ba2793dc1dbd6d3ab01aaae6485222945774c7d7a9a2e9fb87e0d8ef1ea96893aa6906147a371bb" type="text/css" />
    <link rel="stylesheet" href="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/components/jquery-typeahead/dist/jquery.typeahead.min.css?v=5edf53bf6bb9c3b1ddafd8594825a7e2ed621f19423e569c985162742f63911c09eba2c529f8fb47aebf27fafdfe287d563347f58c1126b278189a18871b6a9a" type="text/css" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    
    

    <link rel="stylesheet" href="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/style/style.min.css?v=56dfd556850eb17b7998c6828467598a322b41593edc758739c66cb2c3fea98f23d0dd8bf8b9b0f5d67bb976a50e4c34f789fe640cbb440fa089e1bf5ec170bd" type="text/css"/>
    
<style type="text/css">
/* disable initial hide */
div#header, div#site {
    display: block;
}
</style>

    <link rel="stylesheet" href="/user/chrisjsewell-jlab_aiidatree-9zlte1op/custom/custom.css" type="text/css" />
    <script src="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/components/es6-promise/promise.min.js?v=bea335d74136a63ae1b5130f5ac9a50c6256a5f435e6e09fef599491a84d834a8b0f011ca3eaaca3b4ab6a2da2d3e1191567a2f171e60da1d10e5b9d52f84184" type="text/javascript" charset="utf-8"></script>
    <script src="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/components/react/react.production.min.js?v=9a0aaf84a316c8bedd6c2ff7d5b5e0a13f8f84ec02442346cba0b842c6c81a6bf6176e64f3675c2ebf357cb5bb048e0b527bd39377c95681d22468da3d5de735" type="text/javascript"></script>
    <script src="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/components/react/react-dom.production.min.js?v=6fc58c1c4736868ff84f57bd8b85f2bdb985993a9392718f3b4af4bfa10fb4efba2b4ddd68644bd2a8daf0619a3844944c9c43f8528364a1aa6fc01ec1b8ae84" type="text/javascript"></script>
    <script src="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/components/create-react-class/index.js?v=894ad57246e682b4cfbe7cd5e408dcd6b38d06af4de4f3425991e2676fdc2ef1732cbd19903104198878ae77de12a1996de3e7da3a467fb226bdda8f4618faec" type="text/javascript"></script>
    <script src="/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/components/requirejs/require.js?v=d37b48bb2137faa0ab98157e240c084dd5b1b5e74911723aa1d1f04c928c2a03dedf922d049e4815f7e5a369faa2e6b6a1000aae958b7953b5cc60411154f593" type="text/javascript" charset="utf-8"></script>
    <script>
      require.config({
          
          urlArgs: "v=20210514014226",
          
          baseUrl: '/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/',
          paths: {
            'auth/js/main': 'auth/js/main.min',
            custom : '/user/chrisjsewell-jlab_aiidatree-9zlte1op/custom',
            nbextensions : '/user/chrisjsewell-jlab_aiidatree-9zlte1op/nbextensions',
            kernelspecs : '/user/chrisjsewell-jlab_aiidatree-9zlte1op/kernelspecs',
            underscore : 'components/underscore/underscore-min',
            backbone : 'components/backbone/backbone-min',
            jed: 'components/jed/jed',
            jquery: 'components/jquery/jquery.min',
            json: 'components/requirejs-plugins/src/json',
            text: 'components/requirejs-text/text',
            bootstrap: 'components/bootstrap/dist/js/bootstrap.min',
            bootstraptour: 'components/bootstrap-tour/build/js/bootstrap-tour.min',
            'jquery-ui': 'components/jquery-ui/jquery-ui.min',
            moment: 'components/moment/min/moment-with-locales',
            codemirror: 'components/codemirror',
            termjs: 'components/xterm.js/xterm',
            typeahead: 'components/jquery-typeahead/dist/jquery.typeahead.min',
          },
          map: { // for backward compatibility
              "*": {
                  "jqueryui": "jquery-ui",
              }
          },
          shim: {
            typeahead: {
              deps: ["jquery"],
              exports: "typeahead"
            },
            underscore: {
              exports: '_'
            },
            backbone: {
              deps: ["underscore", "jquery"],
              exports: "Backbone"
            },
            bootstrap: {
              deps: ["jquery"],
              exports: "bootstrap"
            },
            bootstraptour: {
              deps: ["bootstrap"],
              exports: "Tour"
            },
            "jquery-ui": {
              deps: ["jquery"],
              exports: "$"
            }
          },
          waitSeconds: 30,
      });

      require.config({
          map: {
              '*':{
                'contents': 'services/contents',
              }
          }
      });

      // error-catching custom.js shim.
      define("custom", function (require, exports, module) {
          try {
              var custom = require('custom/custom');
              console.debug('loaded custom.js');
              return custom;
          } catch (e) {
              console.error("error loading custom.js", e);
              return {};
          }
      })

    document.nbjs_translations = {"domain": "nbjs", "locale_data": {"nbjs": {"": {"domain": "nbjs"}}}};
    document.documentElement.lang = navigator.language.toLowerCase();
    </script>

    
    

</head>

<body class=""
 
  
    data-jupyter-api-token="EC36h18LRE6j6_ZE-_IMVg"
  
 
dir="ltr">

<noscript>
    <div id='noscript'>
      Jupyter Notebook requires JavaScript.<br>
      Please enable it to proceed. 
  </div>
</noscript>

<div id="header" role="navigation" aria-label="Top Menu">
  <div id="header-container" class="container">
  <div id="ipython_notebook" class="nav navbar-brand"><a href="/user/chrisjsewell-jlab_aiidatree-9zlte1op/tree?token=EC36h18LRE6j6_ZE-_IMVg" title='dashboard'>
      <img src='/user/chrisjsewell-jlab_aiidatree-9zlte1op/static/base/images/logo.png?v=a2a176ee3cee251ffddf5fa21fe8e43727a9e5f87a06f9c91ad7b776d9e9d3d5e0159c16cc188a3965e00375fb4bc336c16067c688f5040c0c2d4bfdb852a9e4' alt='Jupyter Notebook'/>
  </a></div>

  
  
  
  







  <span>
    <a id="visit-repo-link" href="https://github.com/chrisjsewell/jlab_aiidatree/tree/ad90a5a40e2d4c480095f59c1967fb4e6bb8502a" class="btn btn-default btn-sm navbar-btn" target="_blank"
       style="margin-right: 2px; margin-left: 4px;">Visit repo</a>
  </span>



  <span>
    <button id="copy-binder-link" title="Copy binder link to clipboard" class="btn btn-default btn-sm navbar-btn"
            style="margin-right: 0; margin-left: 2px;"
            data-url="https://mybinder.org/v2/gh/chrisjsewell/jlab_aiidatree/ad90a5a40e2d4c480095f59c1967fb4e6bb8502a" onclick="copy_link_into_clipboard(this);">
      Copy Binder link
    </button>
  </span>



  
  </div>
  <div class="header-bar"></div>

  
  
</div>

<div id="site">


<div class="error">
    
    <h1>404 : Not Found</h1>
    
    
<p>You are requesting a page that does not exist!</p>

</div>


</div>







<script type='text/javascript'>
    function copy_link_into_clipboard(b) {
        var $temp = $("<input>");
        $(b).parent().append($temp);
        $temp.val($(b).data('url')).select();
        document.execCommand("copy");
        $temp.remove();
    }
</script>


<script type='text/javascript'>
require(['jquery'], function($) {
  // scroll long tracebacks to the bottom
  var tb = $(".traceback")[0];
  tb.scrollTop = tb.scrollHeight;
});
</script>


<script type='text/javascript'>
  function _remove_token_from_url() {
    if (window.location.search.length <= 1) {
      return;
    }
    var search_parameters = window.location.search.slice(1).split('&');
    for (var i = 0; i < search_parameters.length; i++) {
      if (search_parameters[i].split('=')[0] === 'token') {
        // remote token from search parameters
        search_parameters.splice(i, 1);
        var new_search = '';
        if (search_parameters.length) {
          new_search = '?' + search_parameters.join('&');
        }
        var new_url = window.location.origin + 
                      window.location.pathname + 
                      new_search + 
                      window.location.hash;
        window.history.replaceState({}, "", new_url);
        return;
      }
    }
  }
  _remove_token_from_url();
</script>
</body>

</html>

It will be broken until a new release of typescript-eslint (should be soon):

typescript-eslint/typescript-eslint#2010 (comment)

Version specifiers for node and Python differ when targeting pre, post releases. The python function packaging.version.parse is able to convert semver version to Python version. But that means adding it as dependency for all extensions. Should we modify the cookiecutter to handle that or should we let power user using pre, post-releases handle the version as they see fit?

I receive the following warning during the package build:

$ python setup.py sdist bdist_wheel
# output truncated for visibility ...
warning: check: missing meta-data: if 'author' supplied, 'author_email' should be supplied too

I could get rid of that warning by adding "author_name" to the package.json and referencing it in setup.py.

I'd be glad to open a PR on this, if that's something you want to have fixed. :)

Since 2 days, the check browser test is failing due to the usage of [email protected].

An issue is opened there: puppeteer/puppeteer#5674

Description

Freshly seeded extension from cookiecutter will fail check_release test because of incorrect relative paths to ui-tests scripts in /ui-tests/README.md and outdated link to https://playwright.dev/docs/intro/ (now https://playwright.dev/docs/intro - no trailing slash):

FAILED ui-tests/README.md::/home/runner/work/myextension/myextension/.jupyter_releaser_checkout/ui-tests/README.md <a href=https://playwright.dev/docs/intro/>
FAILED ui-tests/README.md::/home/runner/work/myextension/myextension/.jupyter_releaser_checkout/ui-tests/README.md <a href=../playwright.config.js>
FAILED ui-tests/README.md::/home/runner/work/myextension/myextension/.jupyter_releaser_checkout/ui-tests/README.md <a href=../jupyter_server_test_config.py>

The bigger problem is that we are not testing the tests.

Reproduce

1. Cut cookies with all settings default but enabled tests
2. Push to GitHub
3. Check release fails

Expected behavior

Tests pass.

Context

3.0 branch

Description

In QuantStack/jupyterlab-js-logs#24 we noticed the JupyterLab extension was released with development (non minified) assets.

This issue is here as a reminder to check if that's the case with this cookiecutter when we generate a brand new extension.

Reproduce

• Generate a new extension
• Build the assets with the jupyter-releaser
• Check the assets in the labextensions folder are minified

Context

cc @hbcarlos we can track that observation here to make sure this is handled by the cookiecutter

At the moment the 3.0 branch of the cookiecutter mentions how to install the extension, but doesn't say how to release to PyPI and conda-forge:

https://github.com/jupyterlab/extension-cookiecutter-ts/tree/d8c08687f8661545a65d65ab8eb9433267a45b35/%7B%7Bcookiecutter.python_name%7D%7D

We should a section with the following commands:

python setup.py sdist bdist_wheel
twine upload dist/*

Problem

It would be great to start encouraging extension authors to create / test their extensions with the JupyterLab 4 and Notebook 7 pre-releases using this cookiecutter.

Proposed Solution

• Create a new 4.0 branch to update the packages to the latest 4.0 pre-release.
• Document it in the README: cookiecutter https://github.com/jupyterlab/extension-cookiecutter-ts --checkout v4.0.

Additional context

The 3.0 branch would still remain the default branch for now. Changes landing on 3.0 could then be backported to 4.0.

Moved to gnestor/jupyterlab_json#1

Description

With the packaging approach taken in this repo, the wheel will contain twice the labextension:

• once installed in /lib/python*.*/python_pkg_name/labextension/
• once installed in /share/jupyter/labextensions/

I suppose it was done this way so that the Python module can find the version looking at the package.json of the labextension?

Expected behavior

Include the labextension only once, not installing the labextension under site-packages as it should not be needed there.

It would be nice to add the structure for unit tests with jest to this cookiecutter by default.

This would let extension authors quickly get started with testing, as it often requires knowing what dependencies to include and what structure to follow (currently documented in https://jupyterlab.readthedocs.io/en/stable/extension/extension_dev.html?#testing-your-extension).

Additionally there could also be end to end tests (for example with galata, although this might require the cookiecutter to do a bit more than logging with console.log.

#149 added a CI check to install from the sdist and make sure the extension is correctly bundled and installed without triggering a new build.

We can add something similar to the extension workflow itself too:

https://github.com/jupyterlab/extension-cookiecutter-ts/blob/3.0/%7B%7Bcookiecutter.python_name%7D%7D/.github/workflows/build.yml

I have no clue, maybe I[m doing things wrong,]
but any modif I do to index.css of an extension have no effect.
It does if I apply them to base... that is unless I cahnge style/index.js to import from index and not base.

Description

Looks like the theme job started failing on CI:

Example run: https://github.com/jupyterlab/extension-cookiecutter-ts/actions/runs/1734417132

With the following error during jlpm install:

error @verdaccio/[email protected]: The engine "node" is incompatible with this module. Expected version ">=14". Got "12.22.9"

Context

This CI check is triggered daily:

Problem

Extension authors creating a new extension from this cookiecutter will very likely want to release it at some point.

For now there is no real instructions for releasing the extension in the cookicutter itself, just a couple of notes in the extension tutorial: https://jupyterlab.readthedocs.io/en/stable/extension/extension_tutorial.html#publishing-your-extension

Ideally, the generated extension would automatically be compatible with the Jupyter Releaser so it can be published to both PyPI and npm: https://github.com/jupyter-server/jupyter_releaser

Proposed Solution

• follow the checklist https://github.com/jupyter-server/jupyter_releaser#Checklist-for-Adoption (adding the missing files and configuration)
• document the release process in the cookiecutter readme

Additional context

This topic was also discussed in #101

Problem

The cookiecutter repo should already be compatible with the Jupyter Releaser: https://github.com/jupyter-server/jupyter_releaser

However we should also add the check release workflow so the generated repo can be continuously tested to be release ready.

Proposed Solution

We add a default Check Release workflow to: https://github.com/jupyterlab/extension-cookiecutter-ts/tree/3.0/%7B%7Bcookiecutter.python_name%7D%7D/.github/workflows

Additional context

Here is an example with the jupyterlab-cell-fash extension which has adopted the Jupyter Releaser for automated releases:

https://github.com/jupyterlab-contrib/jupyterlab-cell-flash/blob/main/.github/workflows/check-release.yml

Cookiecutter ran successfully as of a week ago but now seems borked (I had a previously working version but foolishly said "yes" to download it again!;-):

• missing requirement: jupyter_packaging

In addition, several files appear to be missing, such as:

• src/index.ts
• tsconfig.json

From https://jupyterlab.readthedocs.io/en/stable/extension/extension_tutorial.html#create-an-extension-project, where it says "Change to the directory the cookiecutter created and list the files.You should see a list like the following", I don't:

This was briefly discussed in jupyterlab/jupyterlab#9630

And would be similar to what the jupyterlab_apod repo does: https://github.com/jupyterlab/jupyterlab_apod

Since the JupyterLab upgrade script checks out the 3.0 branch of this cookiecutter to perform the upgrade:

https://github.com/jupyterlab/jupyterlab/blob/58d4f6de6eb8544c88e9580b9b1b35416f0c0173/jupyterlab/upgrade_extension.py#L16

Having 3.0 as default would make it possible to iterate on the cookiecutter without having to backport each change to a separate branch.

cc @fcollonval

It looks like the cookiecutter current requires jupyter_server:

Probably this is only useful when the lab extension also has a server extension. So we could guard this with has_server_extension like in other places.

I just managed to follow till this section: http://jupyterlab-tutorial.readthedocs.io/en/latest/xkcd_extension_tutorial.html#build-and-install-the-extension-for-development

And got these:

"[email protected]" is not compatible with the current JupyterLab
Conflicting Dependencies:
JupyterLab Extension Package

=0.10.0-0 <0.11.0-0 >=0.13.0-0 <0.14.0-0 @jupyterlab/application

What have I done? Or is this repo out of date?

A license file was just added (BSD 3-clause).

I think that for most cookiecutters in the org, we opted for CC-0 #23

I have read @ianhi suggesting using Trove classification https://github.com/pypa/trove-classifiers/blob/master/src/trove_classifiers/__init__.py.

As workaround, we could also enforce jupyterlab3 as keyword that would make it clear that we don't search on server side components of former jupyterlab2 extensions.

pip search jupyterlab3
quirkshop-jlab3-react (0.1.0)  - Quirkshop JupyterLab3 React

pip search jupyterlab
jupyterlab (2.2.9)                            - The JupyterLab notebook server extension.
  INSTALLED: 2.3.0a0
  LATEST:    2.2.9
jupyterlab-server (1.2.0)                     - JupyterLab Server
  INSTALLED: 1.2.0 (latest)
jupyterlab-wipp (0.3.0)                       - WIPP integratio
...

If JavaScript build assets are not there and if jupyter-packaging is not installed, the installation will be broken without any error message. This is due to the following try-except:

https://github.com/jupyterlab/extension-cookiecutter-ts/blob/3.0/%7B%7Bcookiecutter.python_name%7D%7D/setup.py#L72-L84

Running the 3.0 version of cookiecutter-ts, the palette was null.

I was able to work around this by adding the following:

const extension: JupyterFrontEndPlugin<void> = {
    id: 'my-id',
    autoStart: true,
    requires: [IFileBrowserFactory],
    optional: [ILauncher, IMainMenu, ICommandPalette],
    activate: (
	app: JupyterFrontEnd,
	browserFactory: IFileBrowserFactory,
	launcher: IFileBrowserFactory,
	mainMenu: IMainMenu | null,
	palette: ICommandPalette | null
    ) => {
   }
}

I'm not sure exactly what is required to get the palette, but this worked.

I learned over at https://github.com/krassowski/jupyterlab-lsp/issues/518 that extension authors should not only test the installation of federated extension, but the source version too and do it in a clean environment (without the dev dependencies installed). I think that it is important to have this as a step in CI. I think that the default workflow does not do that:

(jlpm run install:extension is an alias for jupyter labextension develop --overwrite .); even if it does (I may be misunderstanding how the cookicutter influences these steps), it would do so in an environment that is tainted with the dev dependencies. Having a clean smoke test, separated out from the build step as we implemented here, using separate jobs and artifact sharing action might be the best practice for preventing issues like this.

Should such an approach be included in the default workflow?