improved menuinst

[ReimarBauer]

Purpose of PR?:

Fixes #2262

Does this PR introduce a breaking change?
moves Menu to conda-build process and menuinst

[ReimarBauer]

we also need the other OS's

[ReimarBauer]

This works now in linux, the other OS's needs to be checked, windows is the next.

[ReimarBauer]

For windows menuinst works too, but on the guacamole system I get a PermissionError which seems not to block the installation in the menu,
conda/menuinst#191

[ReimarBauer]

interesting windows can install all dependencies in a python-3.10

[ReimarBauer]

This works as expected on windows and linux verified on a local conda build.

I expect it also working for OSX but can't easily check that.

[joernu76]

Nice simplification. I do not understand why the bld.bat and build.sh use different last lines, though. Maybe add a comment to that regard?

[matrss]

All of the changes to localbuild/ have to be replicated in the mss-feedstock, right?

I support removing these kinds of things (e.g. also the updater, or anything that deals with packaging matters at runtime) since they make assumptions about how the software is installed that will not always hold true and break something at some point. Also, it is simpler to not have to deal with that stuff.

[ReimarBauer]

localbuild, docs, tutorials, tests, ... are not installed, see MANIFEST.in

We keep them for development. Currenly on localbuild the creation of our docker containers is based on.

A package maintainer for an LTS of Ubuntu will change in his fork a lot more and keep that version over years. When you want to discuss needs of a Linux package Maintainer do that in a different issue.

[ReimarBauer]

All of the changes to localbuild/ have to be replicated in the mss-feedstock, right?

I support removing these kinds of things (e.g. also the updater, or anything that deals with packaging matters at runtime) since they make assumptions about how the software is installed that will not always hold true and break something at some point. Also, it is simpler to not have to deal with that stuff.

Lets look on this seperated from this PR. The dir is not in the MANIFEST.in so it has a similar scope as docs itselfs.
On a different installation than conda someone are not interested on our conda-forge documentations. But because we are based on conda-forge it is important for us.

[matrss]

localbuild, docs, tutorials, tests, ... are not installed, see MANIFEST.in

I don't see how this has anything to do with what I said. I just noted that I think that these changes also have to go into mss-feedstock at some point, i.e. when updating mss-feedstock after the next release.

Currenly on localbuild the creation of our docker containers is based on.

The one in https://github.com/Open-MSS/dockertesting isn't really based on localbuild/, it just parses the dependencies out of meta.yaml, same as what the test workflows in this repo do too. Do we have more container images?

All of the changes to localbuild/ have to be replicated in the mss-feedstock, right?
I support removing these kinds of things (e.g. also the updater, or anything that deals with packaging matters at runtime) since they make assumptions about how the software is installed that will not always hold true and break something at some point. Also, it is simpler to not have to deal with that stuff.

Lets look on this seperated from this PR. The dir is not in the MANIFEST.in so it has a similar scope as docs itselfs. On a different installation than conda someone are not interested on our conda-forge documentations. But because we are based on conda-forge it is important for us.

I think you are misunderstanding me. The quote you replied to is not meant to say that I want to remove localbuild/ (well, I want to, but that is unrelated to this PR as you noted and we have an issue (sort-of) and a proposed PR for that already). The quote is just meant to support the change in this PR generally. It is meant to say that I support removing stuff that deals with packaging matters at runtime, i.e. anything that installs something or updates something or whatever when the package is already installed and running.

[ReimarBauer]

before we merge this I try it on windows again.

[ReimarBauer]

the last change broke it on windows

done
Executing transaction: ...working... done
set PREFIX=C:\Users\r.bauer\miniforge\conda-bld\mss_1714027272548\_test_env
set SRC_DIR=C:\Users\r.bauer\miniforge\conda-bld\mss_1714027272548\test_tmp

(base) %SRC_DIR%>call "%SRC_DIR%\conda_test_env_vars.bat"

(base) %SRC_DIR%>set "CONDA_SHLVL="   &&

(base) %SRC_DIR%>conda activate "%PREFIX%"
import: 'mslib'
import: 'mslib'
Fatal error in launcher: Unable to create process using '"C:\Users\r.bauer\miniforge\conda-bld\mss_1714027272548\_h_env\python.exe"  "C:\Users\r.bauer\miniforge\conda-bld\mss_1714027272548\_test_env\Scripts\mswms.exe" -h': Das System kann die angegebene Datei nicht finden.

WARNING: Tests failed for mss-alpha-py310_1000.tar.bz2 - moving package to C:\Users\r.bauer\miniforge\conda-bld\broken
TESTS FAILED: mss-alpha-py310_1000.tar.bz2

[ReimarBauer]

Nice simplification. I do not understand why the bld.bat and build.sh use different last lines, though. Maybe add a comment to that regard?

Trying again with the same, but it looks like I have to ping for resolving https://docs.conda.io/projects/conda-build/en/stable/user-guide/tutorials/build-pkgs.html#writing-the-build-script-files-build-sh-and-bld-bat

first.

[ReimarBauer]

unfortunatly the hardware I can use for a build example needs 2h

old style
%PYTHON% setup.py install --single-version-externally-managed --record record.txt

mamba list

windows_successful_build.txt

highlights: setuptools 69.5.1, python 3.10.14, pip 24.0

[ReimarBauer]

Seems also on linux the minimum python version has changed

highlights: setuptools 69.5.1, python 3.10.13, pip 24.0

mss_linux.txt

[ReimarBauer]

After this is fixed
conda/menuinst#191 (comment)
and I added it back we should merge this PR.

Afterwards that setup can be used to track down the other problem.