# Is there support / plans / acceptance of domain-specific distributions built on top of jupyterlab-desktop?

**URL:** <https://discourse.jupyter.org/t/is-there-support-plans-acceptance-of-domain-specific-distributions-built-on-top-of-jupyterlab-desktop/12635>\
**Category:** extensions\
**Created:** [January 18, 2022, 4:12pm UTC](https://discourse.jupyter.org/t/is-there-support-plans-acceptance-of-domain-specific-distributions-built-on-top-of-jupyterlab-desktop/12635 "2022-01-18T16:12:30Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![nicholdav](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/nicholdav/32/4312_2.png) [@nicholdav](https://discourse.jupyter.org/u/nicholdav)\
**Post date:** [January 18, 2022, 4:12pm UTC](https://discourse.jupyter.org/t/is-there-support-plans-acceptance-of-domain-specific-distributions-built-on-top-of-jupyterlab-desktop/12635/1 "2022-01-18T16:12:30Z")

</div>

Hi all,

Just curious if there’s been any discussion of making it possible for domain-specific researchers to somehow provide jupyterlab-desktop _plus_ a set of packages specific to their domain?

E.g. `astrolab` would have `astropy` and related packages already installed.

This would be particularly useful for someone who is planning to develop domain-specific pre-built Javascript plug-ins (namely, me).

This might be a bad idea for multiple reasons I don’t understand. Please feel free to tell me about them.

Thanks,  
David

---

<div class="post-metadata">

**Author:** ![krassowski](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/krassowski/32/1685_2.png) [@krassowski](https://discourse.jupyter.org/u/krassowski)\
**Post date:** [January 19, 2022, 2:43pm UTC](https://discourse.jupyter.org/t/is-there-support-plans-acceptance-of-domain-specific-distributions-built-on-top-of-jupyterlab-desktop/12635/2 "2022-01-19T14:43:24Z")

</div>

Yes, this was discussed in [Host a JupyterLab metapackage · Issue #23 · jupyterlab-contrib/jupyterlab-contrib.github.io · GitHub](https://github.com/jupyterlab-contrib/jupyterlab-contrib.github.io/issues/23) and I would love to have this too!

---

<div class="post-metadata">

**Author:** ![nicholdav](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/nicholdav/32/4312_2.png) [@nicholdav](https://discourse.jupyter.org/u/nicholdav)\
**Post date:** [January 19, 2022, 3:29pm UTC](https://discourse.jupyter.org/t/is-there-support-plans-acceptance-of-domain-specific-distributions-built-on-top-of-jupyterlab-desktop/12635/3 "2022-01-19T15:29:41Z")

</div>

Perfect, thank you @krassowski – I had a feeling you were one of the people who would know, and I also had a feeling @tonyfast and @bollwyvl would have opinions about this already 🙂

I will read that issue in detail, thank you.  
I would definitely be willing to help dry run this process.  
The “quantum chemistry” use case built with `constructor` that @bollwyvl describes in this comment sounds like what I have in mind: [Host a JupyterLab metapackage · Issue #23 · jupyterlab-contrib/jupyterlab-contrib.github.io · GitHub](https://github.com/jupyterlab-contrib/jupyterlab-contrib.github.io/issues/23#issuecomment-955401630)

To be clear, I’m thinking of something that’s more like a “domain-specific distro” than a metapackage.  
So you could have:

- geojupyterlab-desktop
- astrojupyterlab-desktop
- quantum-jupyterlab-desktop
- molecular-simulation-…
- etc.  
each managed by the community.

I’m not sure if this would be of interest to, say, `astropy` right now given they have a good thing going.

But I also think there are a lot of domains that really need more GUI functionality, and being able to just build on top of `juptyerlab-desktop` instead of dealing with all the Python ecosystem GUI pain points could be a huge draw for them

---

<div class="post-metadata">

**Author:** ![bollwyvl](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/bollwyvl/32/904_2.png) [@bollwyvl](https://discourse.jupyter.org/u/bollwyvl)\
**Post date:** [January 19, 2022, 8:22pm UTC](https://discourse.jupyter.org/t/is-there-support-plans-acceptance-of-domain-specific-distributions-built-on-top-of-jupyterlab-desktop/12635/4 "2022-01-19T20:22:34Z")

</div>

Right: threw this out on today’s lab call, but theoretically, one could reverse-engineer the current repo into a [cookiecutter](https://github.com/cookiecutter/cookiecutter) that, by default, would emit the same content right back out. This might be better than re-architecting the existing repo.

From some previous efforts to this effect (abandoned for other reasons), the strings that would need replacing are:

```auto
    REPLACEMENTS = {
        "JupyterLab Desktop": "{{ cookiecutter.product_title }}",
        "https://github.com/jupyterlab/jupyterlab-desktop/issues": "{{ cookiecutter.issues_url }}",
        "https://github.com/jupyterlab/jupyterlab-desktop/releases/latest/download/latest.yml": "{{ cookiecutter.releases_yaml_url }}",
        "https://github.com/jupyterlab/jupyterlab-desktop/releases": "{{ cookiecutter.releases_url }}",
        "https://github.com/jupyterlab/jupyterlab-desktop": "{{ cookiecutter.repo_url }}",
        "/jupyterlab-desktop/": "/{{ cookiecutter.package_path_unix }}/",
        "\\jupyterlab-desktop\\": "\\{{ cookiecutter.package_path_win }}\\",
        "JupyterLabDesktop": "{{ cookiecutter.product_path }}"
    }

```

As a downstream, one could then choose to:

- manually…
  - runing the cookiecutter (once)
  - check it in
  - hack on it
  - never update it
  - push
  - wait for CI
  - download the releases

- or, in an automated fashion…
  - running the cookiecutter
  - automated patching the generated repo
  - check _that_ in (so that e.g. the _crucial_ github actions work correctly)
  - push
  - wait for CI
  - download the releases

Or a hybrid of the two:

- e.g. generate a workflow that can propose PRs when the upstream changes.

As for dependency robustness: there are a few places (like the [construct.yaml](https://github.com/jupyterlab/jupyterlab-desktop/blob/eab86c66c630a2206ef4c6df248af83ece193d01/env_installer/construct.yaml)) where the specificity/auditability of the product could be substantially improved (e.g. by injecting `conda-lock` outputs).

---

<div class="post-metadata">

**Author:** ![nicholdav](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/nicholdav/32/4312_2.png) [@nicholdav](https://discourse.jupyter.org/u/nicholdav)\
**Post date:** [January 20, 2022, 5:04pm UTC](https://discourse.jupyter.org/t/is-there-support-plans-acceptance-of-domain-specific-distributions-built-on-top-of-jupyterlab-desktop/12635/5 "2022-01-20T17:04:26Z")

</div>

Looks useful, thank you @bollwyvl – need to put some other pieces in place but will definitely come back to this