Expect Leo 6.8.7 on Friday, October 10

[Edward K. Ream]

Python 3.14 is planned for Tuesday October 7, so it would be convenient to release the next version of Leo three days later. Of course I'll release Leo 6.8.7 earlier if there is reason to do so.

Edward

[Edward K. Ream]

On Friday, August 22, 2025 at 4:15:29 PM UTC-5 Edward K. Ream wrote:

Python 3.14 is planned for Tuesday October 7, so it would be convenient to release the next version of Leo three days later. Of course I'll release Leo 6.8.7 earlier if there is reason to do so.

I have just installed Python 3.14 without incident. All of Leo's tests pass on Windows. I plan to release Leo 6.8.7 this Friday, October 10, as scheduled.

Edward

[rengel]

Hi,

yesterday I updated my machine from Windows 10 to Winddos 11. Today, I completely removed all my old Python installations and then installed the new Python 3.14. From Python I did a fresh install of Leo from PyPi (`python -m pip install leo`) as described on the Leo website. During the install I got the following WARNING:

When I start leo, I get the following error:

The environment contains the correct paths to Python and Python\Scripts.

[Viktor Ransmayr]

@rengel,

rengel schrieb am Donnerstag, 9. Oktober 2025 um 16:43:08 UTC+2:

Hi,

yesterday I updated my machine from Windows 10 to Winddos 11. Today, I completely removed all my old Python installations and then installed the new Python 3.14. From Python I did a fresh install of Leo from PyPi (`python -m pip install leo`) as described on the Leo website. During the install I got the following WARNING:

When I start leo, I get the following error:

The environment contains the correct paths to Python and Python\Scripts.

You installed the latest version of Leo from PyPI, which is version 6.8.6.1.

This version does NOT yet support Python 3.14.0 !

If you want to try it out before Edward releases version 6.8.7, you have to use the 'devel' branch from GitHub.

See https://leo-editor.github.io/leo-editor/installing.html#installing-leo-from-github

With kind regards,

Viktor

[Thomas Passin]

I don't think that's it - PyQt6.sip normally gets installed during a PyQt6 installation. 

[Thomas Passin]

I just installed Python 3.14 on Windows 11. Then I created a new virtual environment and pip-installed Leo into it. PyQt6.sip got installed and Leo ran normally. Something went wrong when @rengel tried installing Leo, I think, because PyQt6 didn't install normally.

I'd suggest creating a venv like I did and trying it that way.

[rengel]

Thank you for your answers!

I waited for a couple of days to install the latest version of leo. But in vain. I tried both the pip install and the install from github. But in both cases I get the same error shown in my original post. Upon closer inspection, I noticed that neither launchLeo.py nor PyQt6.sip have been installed. And the installation didn't install a Leo home directory for me.

[rengel]

A correction: The installation from github did install launchLeo.py. But starting 'python launchLeo.py' still results in the error: 

ModuleNotFoundError: No module named 'PyQt6.sip'. (I did install the requirements.)

[Thomas Passin]

Pretty strange, all right.  I just installed 6.8.7 into another new venv and it worked as expected. It installed leo.exe into the venv's Scripts directory, which is convenient since you only have to type "leo" to launch.

What version of Python are you using?  It's possible that the PyQt6 install for that version has something wrong with it, I suppose. Or the particular version of PyQt6 has an install problem.

Do you know how to set up a virtual environment (venv) for Python? I think you should try that next (although I don't have an explanation for the missing PyQt6.sip). I'll sketch out what to do, and if you already are familiar with using venvs, just ignore me and proceed with what you know.

Decide on a location.  I will use c:\venv as the base directory. You can use somewhere else, of course. Open a console window and type

py -m venv c:\venv\leo

When the command returns a new virtual environment in the c:\venv\leo directory will have been set up.  To use a venv, you have to activate it. Type

c:\venv\leo\Scripts\activate

to do so. Notice that the prompt changes to remind you that you are using the "leo" venv. Some system and Python paths will have been set up, and the Scripts directory will now be on the path for the duration of the session with the venv. Next install Leo:

py -m pip install leo

When this is done, just type leo. Leo should run. If you still get the error about the missing sip component, then I think it will be time to install an earlier version of Python and try with that. Or maybe try to install an earlier version of PyQt6.  

[lewis]

After updating to Python 3.14 I had the same problem starting Leo.

File "N:\git\leo-editor\leo\core\leoQt.py", line 6, in <module>
    from PyQt6 import QtCore, QtGui, QtWidgets

ModuleNotFoundError: No module named 'PyQt6.sip'

I needed to uninstall packages PyQt6 and PyQt6_sip, then reinstall. Leo then worked fine. Both my desktop PC and laptop had the same issue.

There have been other packages which did not work correctly with Python 3.14 and a package reinstall was needed.

[Thomas Passin]

That's one reason to try to install to a new venv.  There won't be any left-over bits to confuse the installer.

[rengel]

@lewis, @tbp1

Thank you both for chipping in. I tried both your suggestions. 

Deleting old relics of PyQt6* and a fresh reinstall of PyQt6 in the main Python installation solved all the problems; 

and using a venv with a simple 'pip install leo' worked as well. 

Finally I settled for the venv solution!

Thanks again!

Reinhard

[rengel]

I used Grok extensively to help me solving this issue. In case somebody is interested in the dialog, here is the link:

https://grok.com/share/c2hhcmQtMg%3D%3D_abe479b8-59c3-46db-b21a-35be3f2be2dc

It is rather long, but it leads from describing the issue to clean starting Leo from the Windows taskbar. 
(It also shows my lack of experience in these matters; but that's another topic...)

[Thomas Passin]

Some of the things that the chatbot suggested aren't really the best, and in some cases seem to be wrong, even though you succeeded. For example, suggested batch file run_leo.bat isn't necessary in a venv. On install Leo creates a launcher in the Scripts directory.  After activation, typing "leo" will launch it. What is helpful to to have a batch file in your path that both activates the venv and launches Leo.  That way you don't have to type the path the the activate script.

Another mistake is that py -m leo won't launch leo. The right command is py -m leo.core.runLeo (there are other possibilities too). But as I said, once the venv has been activated, a simple leo is enough.

Here's a minimal batch file that will activate the venv and run Leo.  It assumes that the name of the venv is "leo"  Just change the path to suit your own location:

setlocal
call c:\tom\venvs\leo\Scripts\activate
py -m leo.core.runLeo %*
endlocal

You need the "call" command in Windows because without it the script will stop after that line.  On linux, replace"call" with "source". The setlocal/endlocal (Windows only) remove path and other environmental variable changes that may happen during the activation and Leo session (which probably wouldn't be a problem for you but it's good practice anyway).

Another thing that can happen, and can cause version conflicts and unexpected behavior when a program or packages are removed.  It's the distinction between installing into the main Python location and the user's location.  The user location is specific to each user, and you install into it using the "--user" option: py -m pip install --user leo.  With a venv, there is no distinction.  "--user" isn't allowed, and all installs go into the venv.  The chatbot's suggestions didn't use "--user". Usually it's considered better to install most things with "--user". In case something in the system-level Python locations gets used for system purposes, keeping other installs in the user's locations can prevent version conflicts and the like. This is more important on Linux than Windows but it's still a good practice to use "--user" when possible.

Now what will happen if you install one program that uses, say, PyQt6 as user, and install another program that also uses PyQt6 without the "--user" option? You might end up with different versions of PyQt6 in the two locations. Python sets up the paths to search the user's locations first.  So if you use Pip to uninstall PyQt6, and then run Python, it will still use the other version of PyQt6. Or fail to, if the other install becomes broken somehow.

In other words, there can be hidden and unexpected results if sometimes one installs using "--user" and sometimes one doesn't. I have done this to myself more than once. Using a venv makes this kind of problem go away. It also prevents errors that happen when the pip command runs a different version of Python than what you expected.  That can happen, for example, when you have multiple versions of Python installed.  It is recommended to launch Pip using py -m pip to

prevent this problem.  With a venv, the right versions are always run and this issue doesn't come up.

[rengel]

@tbp1...

Thanks for your detailed comments about the finer details of pip. As I said, I settled for the venv solution; and up to now it runs flawlessly.  I'm on a single-user machine in my private home. So no one else will ever install anything on this machine. My main Python installation doesn't contain PyQt6. Everything is localized in the venv.

For me it is important that I can start Leo from the taskbar. For that, the batch file is needed. The last part of my conversation with Grok was mainly about debugging the batch file that Grok initially suggested.  As you might have seen, the final version of this batch file does contain the 'call' command, because the first version indeed stopped after the first line. And the answer to my last question of the conversation helped me to get that clickable Lion icon on the taskbar faster, than I could have done on my own, because those pesky details slip may memory way too fast.

Thanks again!

Reinhard

[Thomas Passin]

Another easy way to start Leo is to use the Run dialog you get by typing <Windows key>+R. After you have done this once, the command is remembered and available in the dialog - scroll up or down a step or two if it's not there at the beginning.  In my case, here's the command I use; it launches a batch file that starts Leo using the version in my Git repository:

py-leo-git --theme=tbp_dark

I find it easier to start Leo this way than by clicking on an icon, but of course YMMV.

[rengel]

This inspired me to add a shortcut to the properties dialog of my Leo icon. Now I can start Leo just by clicking: Ctrl+Shift+L.

The complete Target is: 

C:\Windows\System32\cmd.exe /c "C:\venvs\leo\run_leo.bat"

As Run is Minimized, the command window doesn't show up.

The complete run_leo.bat is:

@echo off
echo Activating virtual environment...
call C:\venvs\leo\Scripts\activate
echo Launching Leo...
leo
if %ERRORLEVEL% NEQ 0 (
    echo Error: Failed to launch Leo. Check the error message above.
    pause
)
echo Deactivating virtual environment...
deactivate

[Thomas Passin]

Yes, that's another good way.  I have some shortcuts like that I've used for years, but I haven't made one for Leo yet.

[jkn]

I don't really run Leo under Windows these days, but I remember having to take some time working out a batch file and set of properties like that when running Leo under Cygwin, or MSYS. IMO it would be worth putting something like the above into the documentation.