Renaming / branding - Githubissues

mamba-org / gator

Conda environment and package management extension from within Jupyter

Other

260 stars 30 forks source link

Renaming / branding #88

Open SylvainCorlay opened 4 years ago

SylvainCorlay commented 4 years ago

Do you think it would be interesting to rename the project into "conda / mamba navigator" now that it has a standalone mode? (we also thought of of "gator" :).

Happy to discuss this in person! cc @jtpio @fcollonval

fcollonval commented 4 years ago

Hey yes we can definitely discuss about it. I'm available next week if you want.

Regarding the new name, the main question I have is more about how to avoid update break for the user. One idea would be to have a multiple outputs conda recipe.

jtpio commented 3 years ago

Posting for visibility. Here is the plan and ideas we discussed in person:

[ ] Base the Navigator on lumino Application and not JupyterLab to reduce its size and boundaries (to discuss)
[ ] On the frontend, use a JupyterApp rather than JupyterLab server: https://github.com/mamba-org/gator/issues/92
[x] Rename the Python package to mamba-gator, do a release of the package with JLab2, classical NB and the Navigator support
[x] ~~It should inform classical NB user that this is the latest release. In the future, they will need to use the stand alone Navigator.~~
[x] In classical NB the old entry points in tree and notebook open the stand alone navigator in a new tab
[ ] Then migrate to JLab3 (https://github.com/mamba-org/gator/issues/89) and drop support for the classical Notebook

Items 1 and 2 can be tracked separately and shouldn't affect the renaming / branding.

Items 3 and 4 can be done now. Then we can tackle item 5 to add support for JupyterLab 3+ on master.

@fcollonval feel free to correct if some details are missing or need to be updated

fcollonval commented 3 years ago

Thanks @jtpio

fcollonval commented 3 years ago

Now that #95 and #97 are in. We could move ahead with a release of a single package and ensure backward compatibility for the conda package by creating two outputs packages: one named mamba-gator (to match the one on pip) and one jupyter_conda (to trigger update on existing installation).

I propose as final naming: common => @mamba-org/gator-common (@mamba-org/common is to generic if other mamba projects start publishing on npm) labextension => @mamba-org/gator-lab

Regarding versioning, I suggest 4.0.0 for python and a common version 2.0.0 for the npm packages (to reflect they are based on JLab 2). Will unmatching version between python and npm brings trouble when migrating to JLab 3?

@jtpio @SylvainCorlay what do you think?

jtpio commented 3 years ago

Thanks @fcollonval.

@mamba-org/common is to generic if other mamba projects start publishing on npm

Yes it would make sense to go for a less generic name (@mamba-org/gator-common sounds good).

Will unmatching version between python and npm brings trouble when migrating to JLab 3?

Normally not. We can then bump the packages to 3.0.0.

When we adopt the new distribution system (which can be done in two steps), users will install the mamba-gator Python package 4.0, which will install the 3.0 extension as federated. And this shouldn't require a major bump for the Python package because JupyterLab 2 will ignore the federated extension placed in /share/jupyter/labextensions.