Skip to content

Windows: Add Jupyter dependencies to GRASS daily builds#6289

Merged
echoix merged 2 commits intoOSGeo:mainfrom
lindakarlovska:windows-add-jupyter-dependencies
Sep 19, 2025
Merged

Windows: Add Jupyter dependencies to GRASS daily builds#6289
echoix merged 2 commits intoOSGeo:mainfrom
lindakarlovska:windows-add-jupyter-dependencies

Conversation

@lindakarlovska
Copy link
Contributor

This PR updates the GRASS setup.hint.tmpl template to include dependencies for running Jupyter notebooks inside GRASS.
It adds the following packages to requires: section:

  • python3-jupyterlab – provides the JupyterLab interface.

  • python3-jupyter-server – the backend server for Jupyter notebooks.

  • python3-ipykernel – allows Python code execution in notebooks.

  • python3-ipython – interactive Python shell for notebook execution.

  • python3-ipywidgets – supports interactive widgets in notebooks.

Next steps:

Once tested in daily builds, these dependencies will also need to be added to the official OSGeo4W build: https://github.com/jef-n/OSGeo4W/blob/master/src/grass/osgeo4w/package.sh

@lindakarlovska lindakarlovska added this to the 8.5.0 milestone Aug 30, 2025
@lindakarlovska lindakarlovska added the windows Microsoft Windows specific label Aug 30, 2025
Copy link
Member

@wenzeslaus wenzeslaus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The relation of python3-jupyterlab and python3-jupyter-server is not clear to me, but that's probably fine. The python3-ipython is for the interactive shell without notebook, no? But including it makes sense. Anyway, I can see reasons for including these on Windows even without the GUI additions.

@landam Any comments on this?

@lindakarlovska
Copy link
Contributor Author

python3-ipython

@wenzeslaus I’ve looked into this in more detail, especially regarding the dependencies of the different packages as you mentioned - I have found the nice figure of it: https://docs.jupyter.org/en/latest/_images/repos_map.png which hopefully clarifies it a bit.

Going also through the dependencies at OSGeo4W https://download.osgeo.org/osgeo4w/v2/x86_64/release/python3/, now I’m leaning towards this approach: just installing the full python3-jupyter metapackage.

It includes the following dependencies:
python3-core
python3-ipykernel
python3-ipywidgets
python3-jupyter-console
python3-jupyterlab
python3-nbconvert
python3-notebook

JupyterLab is probably a bit overkill since in reality we would only need python3-ipykernel (ipython is included in ipykernel), python3-ipywidgets, python3-notebook, and python3-jupyter-server. But the issue is that in the new version of python3-notebook, the python3-jupyterlab is already listed as a requirement (so we would have to install the previous version, see orig file in https://download.osgeo.org/osgeo4w/v2/x86_64/release/python3/python3-notebook/) And at the same time, python3-jupyter-server is already included within python3-jupyterlab. So it seems to me better to simply use a single python3-jupyter package - we might end up installing a few extra things, but it will be clear and simple. Do you agree @wenzeslaus (maybe also @echoix and @nilason are you in? :-))

@lindakarlovska lindakarlovska force-pushed the windows-add-jupyter-dependencies branch from 41544a2 to f50a573 Compare September 11, 2025 12:51
@petrasovaa
Copy link
Contributor

That sounds reasonable to me. It looks like there is no folium or ipyleaflet, which means we can't add it?

Copy link
Member

@echoix echoix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the GitHub workflow already updated for this? (Because we don't install GRASS from the OSGeo4W installer, we build it ourselves in CI)

After merged and working, a PR to the OSGeo4W would be needed with the final solution. It doesn't use that hint file, it creates it inline in the script

@lindakarlovska
Copy link
Contributor Author

Is the GitHub workflow already updated for this? (Because we don't install GRASS from the OSGeo4W installer, we build it ourselves in CI)

After merged and working, a PR to the OSGeo4W would be needed with the final solution. It doesn't use that hint file, it creates it inline in the script

@echoix Thank you very much for the comment - I’m a bit confused now as I found in this commit 6325a18 that the GitHub workflow was already updated for Jupyter quite a while ago (actually by you :-)). I had been under the impression that Jupyter support on Windows wasn’t available yet at all.

But I’m not sure what exactly it means to have Jupyter included in OSGeo4W.yml. Does it imply that we already have full Jupyter support for Windows, including daily builds on the CVUT server (https://wingrass.fsv.cvut.cz/grass85/)? I’m afraid probably not, since as far as I know, the OSGeo4W workflow is not used there, and I haven’t found these dependencies referenced anywhere else in the GRASS codebase except the file mswindows/osgeo4w/setup.hint.tmpl – so I thought that this file still plays a role in the Wingrass daily builds - is that true, or is this file completely obsolete? I’m a bit lost here, and I think others might be too — so some clarification would really help. And it looks like you, @echoix, probably know the most about this at the moment.;)

Also, another question – I found these global builds of OSGeo4W https://github.com/jef-n/OSGeo4W/blob/master/src/grass/osgeo4w/package.sh - do I suppose right that the jupyter dependency (and possibly other dependencies @kratochanna mentioned) should be added to this file?

@lindakarlovska
Copy link
Contributor Author

Btw, I did a comparison of the three places with dependencies and it seems that setup.hint.tmpl is really kind of obsolete but also some kind of important things being in OSGeo4W.yml are missing in osgeo4w package namely e.g. python3-matplotlib and python3-numpy. But I am new to the wingrass issues so I might be completely out of scope :-) so more explanations of how it currently works would be great @echoix.
Here's the comparison:

Dependency Official OSGeo4W builds setup.hint OSGeo4W.yml workflow
avce00 ✔️
cairo-devel ✔️ ✔️
fftw ✔️
freetype-devel ✔️ ✔️
gdal-ecw ✔️
gdal-mrsid ✔️
gdal-devel ✔️ ✔️
gdal303-runtime ✔️
geos-devel ✔️ ✔️
gpsbabel ✔️
gs ✔️
libjpeg-turbo-devel ✔️
liblas ✔️
liblas-devel ✔️ ✔️
libpng-devel ✔️ ✔️
libpq-devel ✔️ ✔️
libtiff ✔️
libtiff-devel ✔️ ✔️
libxdr ✔️
netcdf-devel ✔️ ✔️
pdal-devel ✔️
pdcurses ✔️
proj-devel ✔️ ✔️
proj81-runtime ✔️
python3-core ✔️ ✔️
python3-gdal ✔️
python3-jupyter ✔️
python3-matplotlib ✔️ ✔️
python3-numpy ✔️
python3-pillow ✔️
python3-pip ✔️ ✔️
python3-ply ✔️ ✔️
python3-psycopg2-binary ✔️
python3-pyopengl ✔️
python3-pytest ✔️
python3-pywin32 ✔️ ✔️ ✔️
python3-six ✔️
python3-wxpython ✔️ ✔️ ✔️
regex-devel ✔️
sqlite3-devel ✔️
zstd ✔️
zstd-devel ✔️ ✔️

@lindakarlovska
Copy link
Contributor Author

That sounds reasonable to me. It looks like there is no folium or ipyleaflet, which means we can't add it?

I think so.. That is a really good point as without these libraries we would not be able to display any interactive maps in Jupyter notebooks.. @petrasovaa Do you agree if I make an issue for it at OSGeo4W?

@echoix
Copy link
Member

echoix commented Sep 13, 2025

The situation is kinda weird. From what I understand, historically, OSGeo4W managed to get some builds for GRASS to work. Then, we duplicated their build files in our repo, to get our own standalone builds based on that. OSGeo4W might not have ever used these build files. Then, OSGeo4W changed a bit the way they defined the build files, but we never changed. So we diverge a bit. That's why we have two separate .sh that do almost the same. One that is used by OSGeo4W, and one that is used by us in CI. That difference has already bitten us.
The dependencies that the OSGeo4W package use when using the OSGeo4W installer use a setup.hint that is created by echoing to a file in the build script in that repo.

The workflow in CI is only for CI and the tests done there. The standalone builds are made on a server managed by Martin Landa if I understand correctly. I have no insights on how it is isolated, how dependencies work and how they get updated.

Also, I don't think the OSGeo4W repo allows filing in issues.

@lindakarlovska
Copy link
Contributor Author

The situation is kinda weird. From what I understand, historically, OSGeo4W managed to get some builds for GRASS to work. Then, we duplicated their build files in our repo, to get our own standalone builds based on that. OSGeo4W might not have ever used these build files. Then, OSGeo4W changed a bit the way they defined the build files, but we never changed. So we diverge a bit. That's why we have two separate .sh that do almost the same. One that is used by OSGeo4W, and one that is used by us in CI. That difference has already bitten us. The dependencies that the OSGeo4W package use when using the OSGeo4W installer use a setup.hint that is created by echoing to a file in the build script in that repo.

Well, thank you @echoix for the explanation - I get it .. kind of :-) But it is really hard to understand how this whole win build stuff works.

The workflow in CI is only for CI and the tests done there. The standalone builds are made on a server managed by Martin Landa if I understand correctly. I have no insights on how it is isolated, how dependencies work and how they get updated.

I am almost 100% sure that the file changed in this PR is the one needed for the Martin daily builds but I also do not understand the procedure - It took quite a long time to me to go through files in wingrass-maintainance repo and only thing I have is a big head ;-). Anyway I think we can merge this - @echoix what do you think?

Also, I don't think the OSGeo4W repo allows filing in issues.

I made the PR at OSGeoW4, would be great if anyone would look at it and give a thumb or so that agrees :-): jef-n/OSGeo4W#36

Copy link
Member

@echoix echoix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This by itself is fine

@echoix echoix merged commit 4b09ae3 into OSGeo:main Sep 19, 2025
27 checks passed
@echoix
Copy link
Member

echoix commented Sep 19, 2025

The other PR for OSGeo4W is already opened

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

windows Microsoft Windows specific

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants