Split glue-core into glue-core and glue-qt

[astrofrog]

Now that glue-jupyter is picking up steam, we should press ahead with the plan to split glue-core out into glue-core and glue-qt, so that packages relying on glue-core for Jupyter or other front-ends don't need to be importing anything needed for the Qt Application.

After much thought, I think that the present repository should become the one for glue-core, the frontend-independent package, because it is the one that will likely be around for the duration of the project, and glue-qt should be a separate repository. For now I think we should also not rename this present repo to glue-core (but we could in future).

Given this, my proposed plan is as follows:

• Split out all the Qt-specific code into a separate glue-qt repository which will provide a glue-qt package with a glue_qt module. That repository should also contain most of the present docs, since they are very much centered around the Qt application currently. The glue-qt repository should share the same history as the present repository as - well - they do! (and will make it easier to transition PRs from one to the other) (Initial clean-up to produce glue-qt glue-qt#1)
• Remove all the Qt-specific code from the present repository (Remove Qt-specific code being split into glue-qt #2431)
• Add files to the glue repository which are compatibility imports from glue-qt to glue-core, with deprecation warnings, for now.
• Update the glueviz package to depend on glue-core and glue-qt so that users using the glueviz package should see no change
• Once we have checked that everything is working fine and that none of the glue ecosystem packages use any of the deprecated imports, do releases of all the packages that have been updated as well as glue-core and glue-qt
• Update docs.glueviz.org to point to the glue-qt docs
• Over time we can start moving glue-qt-specific issues over to glue-qt, and moving some of the core (non-Qt) docs over from glue-qt to glue.

At this point, everything should continue to work seamlessly for all users although deprecation warnings will be emitted. Advertise to users that this change is happening.

Once we are confident that we have given enough time for people to adapt (could be a few months), we can drop the glue-qt depdendency from glue-core and also remove all the qt/ sub-packages. This will warrant bumping the version of glue-core to 2.0.0 since it is a pretty major API change.

[astrofrog]

On second thoughts, I think perhaps the glue repo for now should continue to be the Qt specific one and have a new glue-core repository. This would minimize any disruption related to the docs and issue tracker etc. The actual package name in the repo would still have to change to glue-qt instead of glue-core (which it is right now) but I think that should be ok. I've edited the above plan to describe this.

We can then move over any issues and docs that are not specific to the glue-core repository over time.

[astrofrog]

Hmm I keep changing my mind about what should be in the glue repo 😆 (glue-core or glue-qt). I'm just going to do some experiments and will see what I can converge on.

[astrofrog]

I'll go ahead and close this since this is mostly done and will open a dedicated issue about moving docs

[vedant-z]

Hi @astrofrog I was looking for a starter issue to start contributing with GLUE. Let me know if I could be of any help regarding migration of docs or anything related. Or if you have any simple issue which I could start with then please let me know.

Thanks

[pllim]

The deprecation is real annoying. It pops up in Jdaviz and complain about qt import even though Jdaviz does not use the Qt backend at all.

glue/viewers/common/qt/__init__.py:3: GlueDeprecationWarning: Importing from glue.viewers.common.qt is deprecated, use glue_qt.viewers.common instead
warnings.warn('Importing from glue.viewers.common.qt is deprecated, use glue_qt.viewers.common instead', GlueDeprecationWarning)

Should I open a new issue?