jupyterlab
Enable large file support for preview images
Hi, While updating the preview images to better reflect the latest changes, I realize that some of the images (especially the animated gif, one being 342KB) can be heavy.
If we begin to push more changes to the previews, we will end with a pretty unnecessary heavy git repository.
What about enabling git large file storage https://help.github.com/en/github/managing-large-files/configuring-git-large-file-storage ?
This sounds like it could help yes.
Two questions though:
- Are preview images going to change often in the long run?
- Since enabling lfs requires installing a new program (https://help.github.com/en/github/managing-large-files/installing-git-large-file-storage), could that be seen as an obstacle and more work for anyone who would like to contribute to the repository?
We can continue without git-lfs for now and only change the images if really needed. Anyway, they are there to give an idea of what the plugin is doing and not to 100% reflect what the specific user UI will look like.
I have gone trough the previews, and even if some naming have changed based on the latest commits, I feel like they are still representative. So I would not update them in a separated PR.
Let's leave this open for discussion depending on how the examples evolve.
Are preview images going to change often in the long run?
I agree with @echarles comment. But it is maybe the point of view of a seasoned developer and not the one of a newbie.
Since enabling lfs requires installing a new program (https://help.github.com/en/github/managing-large-files/installing-git-large-file-storage), could that be seen as an obstacle and more work for anyone who would like to contribute to the repository?
I would prefer avoiding installing a additional software for lfs.
I agree it's frustrating if the repo grows in size just because of images and screencasts.
If we can make this setup transparent to all contributors then we could enable it.
An alternative would be to upload the images and screencast to GitHub, and use a URL instead. The downside is that it will not be available offline. But still a trade-off to consider.