Leo deployment on Windows - past story, current story

[David Szent-Györgyi]

I've written of the need to discuss the deployment stories on Windows, macOS, various Unix distributions, various Linux distributions. Before this discussion begins, one must consider that there are multiple implementations of Python. For the moment, I'm limiting my comments to CPython running native on Windows. 

Context: The last time I worked on an installer for Leo or any other package, Leo 4.3 was the current release, and came with a single-file installer built using NSIS. That installer was for Windows only. NSIS as it stood then was flexible as it saw use in many projects, but its use was somewhat arcane. My work was aimed at supporting per-user installations of CPython as well as shared installations, and installing per-user and system-wide installations of Leo on top of system-wide installations of CPython; my hope was that the two flavors of per-user support would ease the work of side-by-side testing of multiple CPython releases and multiple Leo releases. By the time I had something to share with Edward, Windows Vista had brought the headaches of UAC dialog boxes that were the user interface for tightened security, and I had not touched those. Edward was already burdened by maintenance of the Windows XP-savvy installer script that NSIS compiles. It's possible that my work only promised more installer-related work for him, but it's Edward's right to comment on that if he wishes to.

Contrast that with the current requirements under Windows:

• CPython;

• Qt, whose publisher has restricted access to the LTS releases to paying customers, which forces non-commercial users to track development versions that are released every six months; 

• Git, or another source code management tool that speaks enough Git to pull from GitHub; 

• Leo's devel branch on GitHub, which mingles Leo's core with Leo's plugins, some of which are clearly essential to leo as it stands.

What are the installer stories for each of these? 

• CPython comes with an installer,  one that supports setups for the individual user and for all users. 

• The changes to Qt distribution are no gift to a project like Leo, if my guess about the limits to Edward's ability to scale are as accurate as my knowledge of my own. 

• Git, I can't speak to. It has arrived since I had spare time to develop software, even limiting development to my narrow requirements.  

• Following Leo's devel branch on GitHub seems to require following discussions among its developers here on Leo-editor. The supportive responses of the people here are a major plus. 

What are the usage stories for each of these? 

Cpython. The current release of CPython is 3.9.5. Its installer supports installation for the current and for all users. It supports access to the pip manager for packages on the Python Package Index ("PyPi"). 

Qt. I don't know about Qt as shipped by its publisher, The Qt Company; on my work Windows machine, I recently installed the Individual Edition of the Anaconda distribution of CPython to obtain it. There's more to say about the Anaconda distribution later. 

Python bindings for Qt. Either Riverbank Computing's PyQt, or the Qt Company's PySide, which was developed by Qt's owner because of Riverbank Computing's restrictive license. Now, Qt is also under a restrictive license. . . .

Git. It is my impression that use of Git is complicated enough that it requires both learning and careful, careful use. I'm old and busy, meaning that I have limitations, and memory for the details of infrequently used command-line utilities is one of them. 

Leo's devel branch on GitHub. I am drawn to the single-file-installer and small-team focus of Fossil-SCM, which is built on engineering choices of simplicity of deployment and use. It supports both server-based repositories and distributed development. It can use an installed Git to work with GitHub repositories while work on the local machine is done with Fossil-SCM. There are limitations to support of GitHub, and Leo's developers would need to comment on those before anyone did more than pull from the Leo's devel branch for deployment. I don't speak for anyone else, but if those limitations don't break the practices of Leo's developers, I'd suggest that people who don't use Git every day to work with GitHub repositories consider using Fossil-SCM. Fossil-SCM and SQLite are developed in tandem; the developers do really eat their own dogfood. 

The Anaconda Distribution of CPython. The 64-bit distribution for Python 3.8 bundles Qt, PyQt and PySide bindings for Python, and a host of data science software including the Jupyter notebook that Edward has looked at recently. The Individual Edition isn't an option available to all; my employer's headcount is small enough that I am not required to pay the Commercial Edition, the cheapest commercial option at 14.95 US Dollars per month, per seat. Note also that the Anaconda distribution uses Conda as a package manager, not pip, and providing a Conda package for Leo is a necessity if the Anaconda distribution is the chosen relief for the limits on scaling of Edward and other developers and the participants on the Leo-editor Google Group. 

[David Szent-Györgyi]

From the documentation for Version 3.8 of the Anaconda distribution:

Conda treats Python the same as any other package, so it is easy to manage and update multiple installations.

Anaconda supports Python 2.7, 3.6, 3.7, and 3.8. The default is Python 2.7 or 3.8, depending on which installer you used:

• For the installers "Anaconda" and "Miniconda," the default is 2.7.

• For the installers "Anaconda3" or "Miniconda3," the default is 3.8.

[David Szent-Györgyi]

From Wikipedia's article on Windows 10: «Starting with Windows 10 version 2004, Microsoft will require new OEM devices to use 64-bit processors, and will therefore cease the distribution of x86 (32-bit) variants of Windows 10 via OEM channels. The 32-bit variants of Windows 10 will remain available via non-OEM channels, and Microsoft will continue to "[provide] feature and security updates on these devices".»

Not that it is a good thing to be heedless of RAM usage, but relief from the address-space restrictions of 32-bit Windows is a Good Thing. 

[Félix]

Thank you David for those informative and enlightening posts about the building/packaging of Leo installers... Much appreciated!

--

Félix

[Matt Wilkie]

I'm popping into the Leo group for a brief dip after a long time away (distracting myself from work I don't like by visiting a place with fond memories and good people). I intended only to lurk, but I can't stop myself from saying "thank you David!" for this cogent and outstanding summary.

I too am continually drawn back to the Fossil and SQLite projects, even though they remain a poor fit for who Iam and what I work with. I re-read ' SQLite As An Application File Format ' every year or so and crawl through Fossil forum every few weeks. I wish it or me were just a bit different.

Re: conda: It would make certain things easier to have a Leo conda package but it's not essential. This is my current install Leo on new machine recipe, it's still too many steps and too technical to be an installer but at least it's easy to repeat.

1. Install miniconda (preferably using Scoop or Chocolately)
2. Create Leo environment
3. Conda install pip (which installs Python and other essentials)
4. Download Leo source code archive, or git clone same
5. Pip install Leo
   

scoop install --global miniconda3

conda config --add channels conda-forge

conda config --set channel_priority strict

conda create -n Leo

conda activate Leo

conda install pip

Install Leo without Git:

scoop install wget

wget https://github.com/leo-editor/leo-editor/archive/devel.zip

7z x devel.zip -o C:\apps

pip install --editable C:\apps\leo-editor-devel

Install Leo with Git:

pushd C:\apps

git clone --single-branch -b devel --depth=100 https://github.com/leo-editor/leo-editor.git

pip install --editable leo-editor

Wrap up: Run Leo >> Menu: Settings >> Desktop Integration >> [register-leo], [add-desktop-links]

Cheers,

Matt

[Thomas Passin]

I don't install from my git clone, and I don't install with --editable.  Instead, I pip-install Leo, whatever version that may be.  This brings in the dependencies that Leo needs.  I run Leo using my git clone by setting the PYTHONPATH variable to point to the clone's directory.  I then run Leo using python3 -m leo.core.runLeo.

In practice, I set the PYTHONPATH environmental variable and issue the run command using a tiny batch file that I call py-leo-git.  It's not hard to create a launch icon for this batch file, so I can have a Leo icon that launches the clone version.

I feel that this approach gives me the maximum simplicity and flexibility, and I don't have to remember what's been installed with --editable or whatever.  I also don't have to remember what the heck things like --editable do.  I can never keep it straight.

When I wanted to start trying out PyQt6 (Leo was already running with PyQt5), I pip-installed it but then moved the entire PyQt6 directory somewhere outside the Python tree.  When I wanted to use it, I added its directory to the PYTHONPATH, and when I didn't, I just omitted it from the PYTHONPATH.  My batch file adds the clone's directory to whatever PYTHONPATH is already set, so this approach runs the clone version no matter where else I've set PYTHONPATH to.

[Matt Wilkie]

pip install without --editable leaves out some files from Leo's root folder. This doesn't stop Leo from working but can be annoying if you try to do one fo the things that needs them. I'm hazy in the details. It's talked about somewhere in the mailing list archive and Github issues. It couldn't be solved without reorganizing Leo's source code tree. (Or: I couldn't solve back then, maybe someone has come up with a solution since).

I like your idea of having a different icon and shortcut for dev version.

-matt

[David Szent-Györgyi]

On creating a shortcut to the .leo configuration directory. This applies to Windows 10; I have yet to test it on Windows 11.

To create a shortcut to the hidden "configuration directory" in one's home folder, configure File Explorer to show hidden files, right-click on the .leo folder in one's home folder, choose "Create Shortcut" from the context menu, then place the shortcut as needed, then configure File Explorer to not show hidden files. 

I am accustomed to creating shortcuts for backing up installed applications, including the folder that contains the application, the folder for housekeeping information that is shared by all users, and the folder for user-specific housekeeping information. For that, I typically create shortcuts to each of these folders, using Windows 10's File Explorer's context menu entry "New->Shortcut". That approach fails when creating shortcuts to a folder that (a) is in one's home folder and (b) has a name that begins with a dot, thereby calling for special treatment. For such a folder, "New->Shortcut" creates a shortcut that does not work. 

I make the shortcut to the .leo folder apply to every user by editing the shortcut's properties, and replacing the C:\username in the Target field with %HOMEPATH% . %HOMEPATH% is a Windows environment variable that is evaluated when the shortcut is used rather than at the time of its creation. 

[Edward K. Ream]

On Wed, Sep 28, 2022 at 9:04 AM David Szent-Györgyi <das...@gmail.com> wrote:

On creating a shortcut to the .leo configuration directory.

Thanks for these tips.

Edward