More consistent naming

[martinRenou]

Fix #57

cc. @jasongrout

[jasongrout]

+1, especially while we're still pretty small and growing.

Just double checking - is it consistently jupyter_lite (i.e., two words) over in JupyterLite for all the various user APIs, not just for jupyter_lite_conf

[jasongrout]

I don't have permission to merge, but I can approve. Thanks!

[martinRenou]

You should have received an invitation to the jupyterlite org and for having commit rights on this repo :) You probably need to accept it. I let you merge then! :)

[jasongrout]

On second thought, I looked through the jupyterlite repo, and they are more consistently treating jupyterlite as one word in the code, even if the config file naming is treating jupyterlite as two words. I think we ought to hold off on the breaking change here to get more clarity on which way we should consistently name things. It may be that they decide to change jupyterlite to have the config file be named jupyterlite_config.json?

[jtpio]

Probably this is unlikely to change in jupyterlite, and I believe jupyter_lite_config.json was chosen since it's similar to jupyter_notebook_config.json or jupyter_server_config.json.

[jasongrout]

Probably this is unlikely to change in jupyterlite, and I believe jupyter_lite_config.json was chosen since it's similar to jupyter_notebook_config.json or jupyter_server_config.json.

Thanks for chiming in, and for some of the context.

[jasongrout]

After thinking about this more and sleeping on it, I was thinking that maybe it makes sense to have the filename be jupyter_lite_config.json, but the sphinx option names be jupyterlite_config, jupyterlite_dir, etc. In other words, I think the only exception to thinking of jupyterlite as one word is the filename, to be consistent with other Jupyter things. This would be consistent with the naming jupyterlite_sphinx, for example.

[martinRenou]

Arf sorry I merged so fast then :S

I agree with you, let's revert and release again.

[jasongrout]

I agree with you, let's revert and release again.

+1 - I think this would be 0.6.0, since this is technically breaking the 0.5.0 api. I don't think we need to put in backwards compatible shims, though, on the thought that most people would not have upgraded to 0.5.0.