Has anybody done this, please share with me. Thanks.
Virtual Box is slow for my laptop, and I need to constantly watch other team communications that are only available on Windows.
PS: I am not efficient in Linux!
I donāt think so, but you may search the development section of our wiki for more information. I donāt use it a lot, for a couple of reasons, and many pages are quite old, and in this case that may be an advantage, because it may contain sections about building and debugging on Windows from before we moved to MSYS2.
I use Visual Studio Code on Linux, because thatās the only version available there, but on Windows Iāve always used the full Visual Studio, in different versions, for my job, and at home.
Is there a specific reason why you mention VS Code, and not the free Community edition?
Not the success story youāre looking for, but sharing my experience. I have tried a couple of times to set up a full Gramps + Addons development on Windows without MSYS2 and havenāt been successful.
To work on Windows AIO issues, I set up an MSYS2 environment and it worked well, especially since the GrampsAIO build was overhauled by @jmichault to be really easy. However, I use that minimally and only for AIO specific issues and testing because itās not set up with all the tools I need/want.
I also have Gramps set up using WSL on Windows and use that for testing code that might affect Linux and also when I need to run unit tests.
Most of the time I work on Windows or WSL with Visual Studio Code. @ennoborg I havenāt used Visual Studio Community Edition for Gramps. Could you share advantages of VS over VS Code? Thanks.
I got. both VS Community and VC. With VS, the problem was GTK support since launching the AIO gramps.exe does not flow the debugging session to the Python Folder project type (it happens a couple of years ago). I wish I could use VS, especially to take advantage of the object model and intelligence it provides. It would be nice, but I take whatever is possible.
I can live with VC+WSL2, I like to know any package to add to it in order to make it work. Any input in this area is appreciated.
VS is a complete IDE, way more mature than VS Code, and I am used to it as a professional, working with C# and .NET. Using VS Code on Windows would give me more work, because itās not what I am used to, and also because it canāt be configured in the way that I can configure VS Code. The latter often requires tweaking of settings in JSON files, where the original has all settings in menuās and dialogs.
For Gramps alone, thereās probably not much of a difference, and on Linux, VS Code is the only thing available, and better than the other products that I know. Iāve worked with the Eclipse IDE earlier, but once I got used to VS (Code) I stayed with that.
One can argue that with the proper plugins, VS Code can be better and faster than VS, especially for non Microsoft languages like Python, and thereās a nice comparison here:
I made a small Gramps XML parser on Linux, using C# and .NET, because it has a lot of XML support built-in, making it very easy to read a backup file, make a few changes, and save it again, and added a simple GUI in Gtk# with a file selector and a log window to make it easier to use. I did all that with VS Code, and when I loaded the project in VS Community Edition on Windows 10, it immediately downloaded the proper GTK package to make it run on Windows too, which was a bit of a suprise, because I hadnāt used VS with GTK on Windows earlier. I normally use it for standard Windows things.
Thanks. In general I recognize VS is more capable (I used it professionally for a long time) and I was wondering if I should bother setting it up for Gramps usage, but it sounds like maybe not necessary at this time.
1 Like
One reason for me to prefer the full IDE, at least for C#, is that when I find a project that targets an older version of .NET, which is not installed, the IDE can either download that old .NET version for me, or change the project settings to the one that I already have, if newer. That makes life easier, next to the fact that I like exploring IDEs, to see what they can do.
When I had such a problem in Linux, with VS Code, it just told me that there was a problem, and provided a link that I could use to download the older .NET version. And if I remember right, that link didnāt work, so I was sort of stuck, until I realized that I could change the .NET version by editing the project file, which helped to get me running again. A capable IDE would be able to do that for me, but thatās for .NET, not Python, so I canāt say whether it is really better for that. And in fact, on Linux, debugging with VS Code is so easy, that I donāt need anything bigger anyway.
1 Like
As I recalled from my failed attempts a couple of years ago with previous versions of VS Community, I set up a Visual Studio solution of a main project consisting of a single grampsw.exe, and a secondary project comprised of the entire Python folders/subfolders underneath gramps. That didnāt work for me. Any breakpoint placed on any Python code in the solution would not be triggered when running under the debugger from the main.
I concluded then that with intimate knowledge of GTK, Windows GUI, and Gramps, one could separate the GUI into separate platform-specific components to add to the core codebase. I have none of these skills. I am wondering if the team that implements the AIO grampsw.exe (and other exe versions) could check the possibility of a main Python code that conditionally imports the GUI elements by platform. This would allow Visual Studio to manage all the Python codes under a single project. It was just a thought.
-dave
When you install Gramps AIO 5.1.6, it will put a Python script called grampsapp.py into
C:\Program Files\GrampsAIO64-5.1.6\gramps
and I bet that you can use that as the startup file for debugging, if you have a proper Python version that VS can find, and the proper paths set in your debugging environment. Gramps AIO uses a sort of embedded Python, which is started by grampsw.exe, or one of the other gramps executables that you can find in the parent folder.
I havenāt tried this myself, but I guess that it can work, because it is the way that Gramps is started in Linux, and the AIO is not that different, other than that it brings its own resources.
How can I get to see the source code, including scripts that build grampsw.exe. Is it on GitHub too?
Thanks and regards.
-dave
The msys2 version is in https://github.com/gramps-project/gramps/tree/maintenance/gramps52/aio
Since the build required a full day of the AIO package maintainerās time, a new workflow was created to build the Windows version. There is a LOOOONG discussion in the PR about evolving that workflow.
Thanks for your pointer. I need time to digest them. I will begin with grampsaiow.py, and will go from there.
2 Likes
When I follow the directions here, I canāt build the AIO, because it runs into a problem with cx_Freeze. I tried this with master and maintenance/gramps52.
@ennoborg A few months ago I was able to build GrampAIO successfully to test PR #1755. Can you share the errors youāre running into?
Sure. I see this on all branches that I tried, like master, maintenance/gramps52, aio-5.2.3, and v5.2.3.
Traceback (most recent call last):
File āC:/msys64/home/ennob/gramps/aio/setup.pyā, line 14, in
import cx_Freeze
ModuleNotFoundError: No module named ācx_Freezeā
./build.sh: line 152: cd: mingw64/src: No such file or directory
Processing config: C:\msys64\mingw64\etc\nsisconf.nsh
Processing script file: āgrampsaio64.nsiā (ACP)
LicenseData: open failed āā¦\share\doc\gramps\COPYINGā
Usage: LicenseData local_file_that_has_license_text | license_lang_string
Error in macro MUI_PAGEDECLARATION_LICENSE on macroline 17
Error in macro MUI_PAGE_LICENSE on macroline 6
Error in script āgrampsaio64.nsiā on line 75 ā aborting creation process
The total log is so long, that I havenāt pinpointed the actual cause yet, but I suspect that itās linked to a new cx-freeze version.
Iāve tested this on my desktop and laptop, both running Windows 10. The HP desktop that I bought in 2020 failed a few weeks ago, and that was the only machine that could run Windows 11 here.
Nick had to rollback the version of cx_Freeze because the latest version resulted in the broken 5.2.3-1 AIO installer earlier this year. If you have cx_Freeze already, the version needs to be downgraded, and if you donāt have it in your MSYS2 set, then install it.
1 Like
@ennoborg
While debugging the now resolved 5.2.3-1 launch failure (bug 13360) I came across a reported bug in cx_Freeze which might have been the cause for our problems. That has since been resolved, and newer versions include the fix for it. Once you get your build working, would you be willing to test with the latest MSYS2 package for cx_Freeze and check whether the generated installer can be built, installed and run successfully? Thank you!
Using Visual Studio Code, a workspace with the gramps folder, and this launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Python Debugger: gramps",
"type": "debugpy",
"request": "launch",
"program": "${workspaceFolder}/aio/grampsaiocd.py",
"console": "integratedTerminal",
"env": {
"PYTHONPATH": "${workspaceFolder}",
}
}
]
}
at least āstartsā gramps in the VS Code debugger. Donāt get too excited though, it does not get any where near the UI. Various python packages are missing and I get a module not found error in const.py on this line
from gi.repository import GLib
If I patch grampsaiocd.py and instead of importing grampsapp, simply call
print("Hello")
then I can set a breakpoint which gets hit as expected.
Iām not sure that this is the right approach to take though; we need the MSYS2 environment. Maybe we can leverage a release install of gramps to provide the correctly configured python environment?
1 Like
Well, when I test with the latest, by uncommenting the downgrade, I run into another problem with spell, that I canāt fix. I also see another error with pip that I also got on LMDE 6 with another package, where I could fix it, and that looks like this:
error: externally-managed-environment
Ć This environment is externally managed
ā°ā> To install Python packages system-wide, try āpacman -S
$MINGW_PACKAGE_PREFIX-python-xyzā, where xyz is the package you
are trying to install.
If you wish to install a non-MSYS2-packaged Python package,
create a virtual environment using āpython -m venv path/to/venvā.
Then use path/to/venv/bin/python and path/to/venv/bin/pip.
If you wish to install a non-MSYS2 packaged Python application,
it may be easiest to use āpipx install xyzā, which will manage a
virtual environment for you. Make sure you have $MINGW_PACKAGE_PREFIX-python-pipx
installed via pacman.
note: If you believe this is a mistake, please contact your Python installation or OS distribution p
rovider. You can override this, at the risk of breaking your Python installation or OS, by passing -
-break-system-packages.
hint: See PEP 668 for the detailed specification.
I could fix it on LMDE 6, where it was a one time thing, and Iām way more familiar with the environment and also had more time.
The good news is, that these errors only affect the build process for the installer, and are not needed for development itself. And that means that @dave.khuon can build and run from source in MSYS2 in the same way as I do on Linux, that is by changing to the gramps directory, and building Gramps with the standard command
python setup.py build
And when thatās done, start Gramps with
python Gramps.py
This does not work in a clean MSYS2, because in that, you have no python, nor any of the libraries that Gramps needs. These are installed by build.sh however, even if it fails at the end.
Youāre pretty close, and I got it working here, with MSYS2 and VS Code. Hereās how it works:
When I install MSYS2 and clone Gramps as described in the readme, I get a gramps folder here:
C:\msys64\home\ennob\gramps
Then, when I checkout the version that I want to work on, and run build.sh in the aio folder, I get a full working python installation, with all the right libraries, which can be started by running
C:\msys64\mingw64\bin\python.exe
Now, even when the build script fails to create a working installer, it does build Gramps, and you can start that by opening Gramps.py in the gramps folder, and telling VS Code to use this python.exe as the debugging environment.
I can do all this without creating a launch.json file, and debug Gramps just like I can debug it on Linux, with VS Code.