Thanks to David, Edward, Victor and others participating in this particular thread about server script file location,
To conclude and move forward with this specific (and important) issue that Victor raised: I tough about this in the last few days and I've come to the conclusion that the server.py script (and its client/test scripts) should go back to their original location: <root-folder>/leo/core so that anyone has them regardless of the installation method that was used to install Leo. (Edward please let me know if you can change this in the devel branch - no rush - sorry to have you revert this! ) To compensate in making the server script easier to find & help the user locate the server script, I will simply make leointeg's "server -location" setting more flexible: I will let it accept either a string folder-path to the leo-editor root installation folder, (leointeg will figure out the specific /leo/core/server.py path from there), or, a .py file-path to a specific server script. (in case a user wants to use a specific server script). Tada! problem solved! -- Félix On Saturday, May 22, 2021 at 9:57:24 PM UTC-4 David Szent-Györgyi wrote: > On Thursday, May 20, 2021 at 1:39:06 PM UTC-4 [email protected] wrote: > >> In my view, Leo *is* a 3rd party python package and should be installable >> via pip. It is true that some Linux systems will tinker with the >> directories, paths, etc and want you to install certain packages using >> their own package manager. But Leo as a project can't cater to all these >> possible variations. >> >> I can see a separate pip package named, say, "leo-server" or some such >> that includes the parts that you want to work with that ordinary users >> can't. Such a package could I'm sure be created by a script that creates a >> temporary directory tree with the extra parts for the packager to package >> up. Or maybe the existing setup.py can be enhanced to do that. >> > > The last time I worked on an installer for Leo or any other package, Leo > 4.3 was the current release. That installer was for Windows only, and used > NSIS to generate the single-file setup executable. 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, he was already > burdened by maintenance of the source code of the 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. > > If I recall correctly, Leo releases are less frequent than was the case > when Leo 4.2, 4.3, and 4.4 were under development. Stabilizing Leo for a > release requires work. It is also the case that an installer requires a > matching uninstaller. Serious effort is made to minimize the periods during > which the most recent commit devel branch on GitHub is unusable; as such, > the expectation is that one needs to pull from the devel branch in between > releases. > > Pip is for packages; I question whether Leo with its Qt -based GUI and > with its plugins is best considered as a single package. In my days working > with Leo with the Tkinter-based GUI and working solely on Windows, all I > needed was the the single-file installer for CPython, the single-file > NSIS-based installer executable for Leo, and the single-file installer for > Mark Hammond's pywin32 tools - I could fit the installers on a rewritable > CD, and install them on a new machine in three minutes, and understand the > process without documenting it. > > Making Leo easier to install across deployment targets may increase the > volume of requests for help, and my experience providing technical support > for software published by my employers is that addressing deployment > strategies in the software itself is critical to allowing the support staff > to scale. > > Python is a great language for writing scripts and many sorts of > applications, but its deployment story does not deliver the application > publisher a one solution-fits-all across Windows, macOS, the various Unix > distributions, and the various Linux distributions. The details of the > requirements for the different deployment targets vary so greatly that I've > just abandoned detailing those known to me here; a serious attempt to > catalogue them for the use of Leo's developers needs to be addressed > separately. > > That said, I think all those details need to be laid out for Leo's > developers to consider; the rearrangement of Leo's source code for pip is > only a start on the changes needed to support deployment, and I am sure > that improvement of minimal support for all the targets listed in the > preceding paragraph would require changes within Leo itself. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/a1415fc3-c850-42d8-9869-76edcbc3ef6an%40googlegroups.com.
