Skip to content

Conversation

@zklaus
Copy link
Contributor

@zklaus zklaus commented Sep 3, 2025

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

Closes #197
Closes #196

This is based on the bot auto update and @ReimarBauer's work in #196. Additionally, it adds the entry points to the recipe.

@conda-forge-admin
Copy link
Contributor

conda-forge-admin commented Sep 3, 2025

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

  • ℹ️ Recipes should usually depend on matplotlib-base as opposed to matplotlib so that runtime environments do not require large packages like qt.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/17425878984. Examine the logs at this URL for more detail.

@conda-forge-admin
Copy link
Contributor

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

…5.09.02.23.06.43

Other tools:
- conda-build 24.3.0
- rattler-build 0.18.1
- rattler-build-conda-compat 1.4.5
@zklaus zklaus mentioned this pull request Sep 3, 2025
4 tasks
recipe/meta.yaml Outdated
- fs_filepicker >=0.3.9
- cftime >=1.0.1
- matplotlib >=3.5.3
- matplotlib-base >=3.5.3
Copy link
Contributor

Choose a reason for hiding this comment

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

the msui will need the qt bindings, https://mss.readthedocs.io/en/stable/tutorial.html
that is not the major issue here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree that this was not the show stopper. It's just considered good practice. I don't know if people ever use mss without the gui elements, but the number of cli options suggests they do. In that case, it's better not to force every user to install the full GUI stack.

Copy link
Contributor

@ReimarBauer ReimarBauer Sep 3, 2025

Choose a reason for hiding this comment

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

We have only few server setups but many GUI users. Usually you need a connection to the ECMWF weather cloud, or provide your own model data by using a server.
There you need likly access to ECMWF or some similiar service.

Example to retrieve data: https://github.com/Open-MSS/data-retrieval
(There is public data available, real time data needs a different access)

The server is based on OGC WMS and extended to be able to provide sideview (vertical) data and data along the flightpath.

Common OGC WMS clients can only show top views. We need for flight preparation, telling the pilot how we want to measure all the features.

Copy link
Contributor

Choose a reason for hiding this comment

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

the other server is a socketIO server for enabling realtime planning and exchanging data.

I started a draft already to split the package for server installation. We have to split modules first. We likly will have later it similiar as basemap has done.

Copy link
Contributor

Choose a reason for hiding this comment

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

we added the other cli options to make it easier to setup own servers by also providing demodata.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good. Feel free to ping me when it comes to packaging.

…5.09.02.23.06.43

Other tools:
- conda-build 24.3.0
- rattler-build 0.18.1
- rattler-build-conda-compat 1.4.5
@zklaus
Copy link
Contributor Author

zklaus commented Sep 3, 2025

I think this is ready now. A few comments:

--no-build-isolation

You already found the relevant documentation, but basically, without this switch, Pip will create a new environment and install the dependencies in there to do the build. This is not desirable for Conda-forge as we want to be in charge of provisioning the build environment, which is particularly relevant in case of binary dependencies.

However, there is another wrinkle, which is that this setting can also be managed by environment variables and this is indeed taken care of by conda-build (iirc), so putting the switch here is more of a reminder and fail-safe; it would be active even without.

Entry Points

The crucial problem here was that the entry points were not listed in the meta.yaml file. They must be repeated in the build.entry_points section (from the pyproject.toml file) to be handled correctly. On Unix, it kind-of-sort-of works without because Pip installs things into the bin folder where they get picked up automatically, but on Windows special treatment with custom trampoline programs is needed, so naming them in meta.yaml is crucial.

Noarch

I wonder if this package could be noarch. At a glance it doesn't seem to contain any binary code. Is that correct?

Bot PRs

I think you started your own PR before the bot opened it's automatic update PR, but just to be clear: if you need to work on something that has been started by the bot already, it is not necessary to make a separate PR. Instead, as a maintainer, you can simply push to the bot branch directly and things will show up in the PR.

@zklaus zklaus changed the title [Do not merge] [debug] updated v10.2.0 Updated v10.2.0 Sep 3, 2025
@zklaus zklaus marked this pull request as ready for review September 3, 2025 15:59
@zklaus
Copy link
Contributor Author

zklaus commented Sep 3, 2025

This PR can be merged as is, I think; but if you prefer, feel free to just take the elements for integration into one of the other PRs.

@ReimarBauer
Copy link
Contributor

ReimarBauer commented Sep 3, 2025

I would like to merge your PR, I also learned a lot here following you.
This would be the only change.

matplotlib-base >=3.5.3 to matplotlib >=3.5.3

We came to conda-forge in 2016 because the conda packaging workflow solves a major issue, people running on us to help installing missing packages on their systems. In the past days I remember USB Sticks added to computers to install missing dependencies.

I never thought about if we can do noarch. But you are right, we don't compile anything.

How does noarch handle the menuinst installation?
Open-MSS/MSS#2881

@ReimarBauer
Copy link
Contributor

I was faster than the bot. And the bot did not recognize that I also worked on it.

@conda-forge-admin
Copy link
Contributor

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

  • ℹ️ Recipes should usually depend on matplotlib-base as opposed to matplotlib so that runtime environments do not require large packages like qt.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/17439420973. Examine the logs at this URL for more detail.

@ReimarBauer
Copy link
Contributor

@zklaus, hope that is ok, I wanted to suggest the change, but on save it committed it directly.

Copy link
Contributor

@ReimarBauer ReimarBauer left a comment

Choose a reason for hiding this comment

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

I'm very grateful for your help with that. I really learned a lot from you.

@ReimarBauer ReimarBauer merged commit a007b77 into conda-forge:main Sep 3, 2025
15 checks passed
@matrss
Copy link
Contributor

matrss commented Sep 3, 2025

I don't understand some of the changes here, but maybe I am just too ignorant on python packaging... I'll ask some questions for documentation purposes and try some things out in a separate PR, but if you have any answers that would be appreciated as well.

  1. Within MSS we only have the "mslib" top-level package. Is it not sufficient to specify the top-level package? Is it required to specify all nested packages as well? Presumably "mslib*" also matches those sub-packages? But why would this only be an issue on Windows, and not everywhere?
  2. Can we get by with the default "flat"-layout? (i.e. not specify anything package-related in pyproject.toml?)
  3. Why was it previously not necessary to specify entrypoints? Is there some way to still keep it DRY? I vaguely remember having read somewhere that they should be taken from the python package metadata...

I agree that if possible this should be a noarch package.

@matrss
Copy link
Contributor

matrss commented Sep 3, 2025

  1. Within MSS we only have the "mslib" top-level package. Is it not sufficient to specify the top-level package? Is it required to specify all nested packages as well? Presumably "mslib*" also matches those sub-packages? But why would this only be an issue on Windows, and not everywhere?

First answer from testing in #199: the changes to package discovery were not needed to build on Windows. But just having "mslib" configured is also not correct, as it produces warnings along these lines:

          ############################
          # Package would be ignored #
          ############################
          Python recognizes 'mslib.msui.icons' as an importable package[^1],
          but it is absent from setuptools' `packages` configuration.

@matrss
Copy link
Contributor

matrss commented Sep 3, 2025

  1. Can we get by with the default "flat"-layout? (i.e. not specify anything package-related in pyproject.toml?)

No, we can't, because tutorials/ is then recognized as a package too, which leads to a build failure since the flat layout only supports a single top-level package.

@ReimarBauer
Copy link
Contributor

ReimarBauer commented Sep 3, 2025

For 3. because we had them in setup.py that's why we haven't them in meta.yaml too.

https://github.com/Open-MSS/MSS/blob/10.0.0/setup.py#L36

Now in 10.2.0 we should expect it is readed from https://github.com/Open-MSS/MSS/blob/10.2.0/pyproject.toml#L22C2-L22C17
This seems not be equivalent how it worked for setup.py.

I would also prefer the definition from pyproject.toml

@matrss
Copy link
Contributor

matrss commented Sep 3, 2025

From a python packaging standpoint, having them in setup.py and having them in pyproject.toml should be equivalent.

The only info I could find on this so far is this: https://conda-forge.org/docs/maintainer/knowledge_base/#:~:text=If%20console_scripts%20entry_points%20are%20defined%20in%20setup.py%20or%20setup.cfg%2C%20they%20are%20also%20listed%20in%20the%20build%20section%20of%20meta.yaml. But it only applies to noarch packages, and only to console_scripts, not gui_scripts (which msui now is, after the switch to pyproject.toml).

@ReimarBauer
Copy link
Contributor

ReimarBauer commented Sep 4, 2025

For switching to noarch we need to figure how menuinst works now, when we don't copy ourselfs the icons. We have to check if we had to do the steps in the scripts or they are meanwhile built-in.

On windows menuinst is a big improvement. The console there has not an utf-8 encoding. common users are not familiar to work with a console. utf-8 ist after more than 10 years still a beta configuration option.

@zklaus
Copy link
Contributor Author

zklaus commented Sep 4, 2025

Menuinst has a section on noarch, though it does not seem to deal with custom icons.

Regarding gui_scripts, I think this may be an inaccuracy in the documentation, which may stem from the fact that most developers work on non-Windows platforms and gui_scripts are essentially a special Windows kind of console_scripts.

@matrss
Copy link
Contributor

matrss commented Sep 9, 2025

I did a quick search for other noarch feedstocks using menuinst and custom icons and found this one: https://github.com/conda-forge/hyperspyui-feedstock/blob/cfa177e37c8ef86670a3dc7227eb5c6332eb47e0/recipe/meta.yaml#L14-L21. It looks like this is pretty straightforward, we would just have to get rid of build.sh and bld.bat and move those instructions into meta.yaml. Since noarch packages are only build on Linux AFAIU there is no need for cmd-compatible build instructions.

@matrss matrss mentioned this pull request Sep 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants