Re: Leo deployment on Windows - past story, current story

[Edward K. Ream]

On Wed, Sep 28, 2022 at 9:04 AM David Szent-Györgyi 
wrote:

> *On creating a shortcut to the .leo configuration directory. *
>

Thanks for these tips.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0n0CzNbL7kQDfiKB_vDk_FBOTH892HOaib55p0z4fhqA%40mail.gmail.com.

Re: Leo deployment on Windows - past story, current story

[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. 
On Saturday, May 22, 2021 at 11:18:23 PM UTC-4 David Szent-Györgyi wrote:

> 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 

Re: Leo deployment on Windows - past story, current story

[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
On Thursday, September 8, 2022 at 8:46:35 p.m. UTC-7 tbp1...@gmail.com 
wrote:

> 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.
>
> On Thursday, September 8, 2022 at 6:44:42 PM UTC-4 map...@gmail.com wrote:
>
>> 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
>>
>> On Saturday, May 22, 2021 at 8:18:23 p.m. UTC-7 David Szent-Györgyi wrote:
>>
>>> 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 

Re: Leo deployment on Windows - past story, current story

[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.

On Thursday, September 8, 2022 at 6:44:42 PM UTC-4 map...@gmail.com wrote:

> 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
>
> On Saturday, May 22, 2021 at 8:18:23 p.m. UTC-7 David Szent-Györgyi wrote:
>
>> 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:

Re: Leo deployment on Windows - past story, current story

[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

On Saturday, May 22, 2021 at 8:18:23 p.m. UTC-7 David Szent-Györgyi wrote:

> 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 

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