Make dscribe an optional dependency

[janosh]

Motivation: This in turn makes numba installation optional which caused issues (see #228 (comment)).

[mkhorton]

Thanks @janosh, added an extra guard statement to ensure localenv.py still mostly works even if the import fails.

[mkhorton]

Otherwise if you're happy with this, I can merge.

Tagging issue #261 here too.

[janosh]

Otherwise if you're happy with this, I can merge.

Go ahead!

[mkhorton]

Just double-checking, I think dscribe should still live inside the pyproject.toml (i.e., it was already optional, but we're removing it from the server install)?

[janosh]

I was confused by the fact dscribe was already marked optional. But also confused about why remove it from the server install?

[mkhorton]

Yes--worth checking! I was premising this discussion on the assumption that you would like to install crystal toolkit with server options, but that dependency solving is currently broken.

Right now, the default install (without any extras) is really just for use in Jupyter.

The install with server extras included allows you to spin up Dash apps, and I imagine this is the installation most people will need if following, e.g., the web app examples.

dscribe was previously a server dependency, because it is required by the local environment component (specified in localenv.py), which one might use to investigate the local environments of a given Structure object, but was not required just for the pure Jupyter use.

[mkhorton]

The question, perhaps, is if the installation is failing even when not installing the server extras?

[janosh]

The question, perhaps, is if the installation is failing even when not installing the server extras?

I wasn't specifying any extras so... yes, I think.

[mkhorton]

Ok, I'll have to take a closer look.

My best guess is that this is happening because of a dependency on mp-api (and emmet-core), i.e. via matminer -- I'm not sure when or why matminer was added as a dependency, but the same issue will be present with the example app too. Hm :/

[mkhorton]

I think we can still merge this in regardless, because loosening the dependency is still a good idea

[mkhorton]

So I think matminer should not be a dependency of emmet-core, asking @munrojm to verify, but may make things easier if this is the case.