buildout neither creates a client1 script nor modifies runwsgi-script.py.
Therefore runwsgi-script.py is only aware of the sys.path created during windows_install.bat.
Question: is bin\runwsgi.exe -dv parts\client1\etc\wsgi.ini the windows way to start client1?
If this is the case, is it possible at all to develop an add-on in windows? Is there anyone who has succesfully developed an add-on with Plone 5.2.8 on Windows 10? Any step-by-step guide?
Using WSL or WSL2, or a VM with of without vagrant, or cygwin or something similary are, of course, excellent ways to get things running in another OS "on top" of Windows. Personally I prefer virtual machines because they can be customized to emulate target production systems and offer snapshots. But this is a personal preference.
But none of the above is sensu stricto "running on Windows".
What I'd like to find out is whether Plone (as of Version 5.2.8 or 5.2.9) can be installed and be used for development on Windows 10 (without WSL or VM).
Has anyone succesfully installed and developed an add-on with Plone 5.2.8 on Windows 10?
mekell via Plone Community wrote at 2022-7-20 07:49 +0000:
...
Has anyone succesfully installed and developed an add-on with Plone 5.2.8 on Windows 10?
A recent discussion targeted how to debug Plone under Windows
(it asked specifically what one can use in place of bin/{client1|instance} debug under Windows).
I suppose that the wish to debug Plone under Windows was
motivated by a serious development project (as a stock Plone
usually does not require debugging).
Thus, the anwser to your question above is likely "yes".
As I already mentioned I suspect that the problem is in buildout: buildout (in Windows 10) always generates exactly the same runwsgi-script.py no matter what configuration (.cfg) is passed to it.
This can be reproduced by running bin\buildout.bat first with buildout.cfg and then with develop.cfg and comparing the generated scripts in the bin directory:
Both buildout.cfg and develop.cfg generate the following scripts (both the .exe and the .py part) with exactly the same content, i.e. the same sys.path: buildout, mkwsgiinstance, repozo, runwsgi, zconsole, zeopack, zeoserver, zeoserver_runzeo, zeoserver_service.
As expected zopepy-script.py is different if generated with develop.cfg: It contains plone.reload in the sys.path if generated with develop.cfg but not if generated with buildout.cfg.
Following scripts (both the .exe and the .py part) are generated with develop.cfg but not with buildout.cfg: bumpversion, develop, diazocompiler, diazopreprocessor, diazorun, fullrelease, i18ndude, lasttagdiff, lasttaglog, longtest, mrbob, pocompile, postrelease, prerelease, release, and test.
Maybe I'm wrong but I'd expect a runwsgi-script.py with the eggs added to sys.path. In the case of develop.cfg I'd expect plone.reload to be in the sys.path. This is not the case. Therefore a client started with bin\runwsgi.exe -dv parts\client1\etc\wsgi.ini cannot have access to plone.reload or any egg not included in the sys.path of runwsgi-script.py.
mekell via Plone Community wrote at 2022-7-20 11:04 +0000:
...
Maybe I'm wrong but I'd expect a runwsgi-script.py with the eggs added to sys.path. In the case of develop.cfg I'd expect plone.reload to be in the sys.path. This is not the case. Therefore a client started with bin\runwsgi.exe -dv parts\client1\etc\wsgi.ini cannot have access to plone.reload or any egg not included in the sys.path of runwsgi-script.py.
Am I correct in assuming the above?
A (buildout) recipe is responsible for the script generation.
Not sure whether Windows requires a different recipe
(on *nix, the corresponding scripts are generated by plone.recipe.zope2instance).
sys.path is generally generated from the eggs definition
of the corresponding section. This is fairly easy: it is quite
difficult to see what could go wrong there.
runwsgi-script.py.as-generated-with-buildout.cfg and runwsgi-script.py.as-generated-with-develop.cfg have exactly the same sys.path. The script runwsgi-script.py.as-generated-with-develop.cfg doesn't include plone.reload in sys.path as I'd expect from the eggs definition in develop.cfg (line 118).
buildout is not responsible for script generation;
it delegates it to a recipe.
Look at the (hierarchical) buildout configuration.
The respective files are organized into (configparser) sections.
The section headers have the form [*section name*].
Some sections describe buildout "part"s. They contain
a definition for recipe. The respective recipe is responsible
for the creation of this part, including associated scripts.
At your place, I would first identify the part responsible
to generate the Plone instance. Under *nix, this is instance or client1. I do not know what it is under Windows.
You may look into the folder parts: its subfolders represent
the candidates. The correct part folder will contain a subfolder etc with files zope.conf and site.zcml.
Once you know the part name, you search the buildout configuration
for the corresponding section and locate its recipe definition.
The recipe is plone.recipe.zope2instance. From its documentation:
On the windows platform the ``bin/instance`` script as described below
will not be generated, because it uses a Unix specific implementation.
To run Plone start it with::
.\bin\runwsgi.exe -v .\parts\etc\wsgi.ini
Or for development in debug mode use::
.\bin\runwsgi.exe -v .\parts\etc\wsgi.ini
The documentation for the extended Zope control script below does not apply.
The source code of plone.recipe.zope2instance doesn't seem to generate the runwsgi scripts at all: Search · runwsgi · GitHub