Python environment management enhancements

[mbektas]

• use conda-pack instead of constructor.
  • This greatly improves Windows install & uninstall experience
  • Enables installations to different disk locations
  • Enables Snap installers for Linux
• use conda-lock to optimize conda env create
• optimize github action builds by using conda lock file for workflow
• Environment management via CLI
  • env install command to install bundled Python environment
  • env activate command to activate bundled Python environment
  • env create command to create new Python environments
  • env info command to show Python env configuration
  • env list command to list environments available to app
  • env update-registry command to update discovered and user set Python environments without launching UI
  • env set-base-conda-env-path command to update base conda environment path

[krassowski]

Some high level questions:

• what are the advantages of using this approach? I presume this would reduce the installation time as the resolution step is eliminated. Anything else?
• how is this going to work with M1 and other architectures which may require a dedicated version of conda binaries?

[mbektas]

@krassowski using conda-pack brings several advantages, some are:

• Windows installation process is improved since users wont need to use Windows installer UI for installing and uninstalling Python environment. This has been causing issues with Windows registry as well.
• Flexibility and more control over Python environment management from app. Now we can install the bundled environment into other locations easily.

Github Actions doesn't have Apple silicon runners yet, that's why we don't bundle an Apple silicon conda env (x64 conda envs still work fine on Apple silicon). But, this PR introduces new CLI options to create environments (jlab env create). Users will be able to create an Apple siicon environment easily using this CLI option. I hope to add UI for managing Python environments later on.

[krassowski]

The Windows installer ballooned even further from 471 MB on latest release to 525 MB in this PR. This is over twice the size of the Debian installed (250 MB). Is there anything we can do to reduce the installer size? As previously mentioned by users elsewhere it is 6 times the size of VS Code installer.

[krassowski]

So unpacked contents are the same size for Debian and Windows installed; the compression just does not work?

[krassowski]

Enabling maximum compression for Windows does not help much (466 MB vs 471 MB) krassowski#21.

[krassowski]

Hmm.. It seems that jlab . to open another project does not work for me anymore? Nor opening a new window in general? I am not 100% positive if this is related. I also see null printed out in terminal when using jlab.

Edit: new window from UI works. It does not work from OS-level integration nor from terminal. Odd.

[mbektas]

Hmm.. It seems that jlab . to open another project does not work for me anymore?

Good catch. I am pushing a fix for this.

[mbektas]

The Windows installer ballooned even further from 471 MB on latest release to 525 MB in this PR. This is over twice the size of the Debian installed (250 MB). Is there anything we can do to reduce the installer size? As previously mentioned by users elsewhere it is 6 times the size of VS Code installer.

7-zip compression is an alternative we can try. We can compress the env installer using 7z.

[Talonkinkade]

merged