Define entrypoints in setup.py instead of meta.yaml

[matrss]

Right now all entrypoints except for msui are declared in meta.yaml only. This has the disadvantage that they are bound to a single package definition for a single package manager. If we moved the entrypoints to setup.py any somewhat decent package manager would pick them up automatically (e.g. nix or pip). They could be dropped from the mss-feedstock as well then, I'd assume.

[ReimarBauer]

This shows the concept how I think we can go with subpages
https://stackoverflow.com/questions/59179316/conda-build-how-to-use-subpackages

• mss as now will be include all (this saves also the namespace)
• mss.msui will be only the msui
• mss.mswms
• mss.mscolab

When the settings are needed in the meta.yaml only I think we can patch setup.py then.

[matrss]

I think this issue and splitting the package into multiple packages are two entirely orthogonal things. If we split the package I'd appreciate it if this wasn't just a conda-specific thing, but a proper split into multiple python packages (so that it can be used as such in other package managers as well).

[matrss]

This shows the concept how I think we can go with subpages https://stackoverflow.com/questions/59179316/conda-build-how-to-use-subpackages

* mss as now will be include all (this saves also the namespace)

* mss.msui will be only the msui

* mss.mswms

* mss.mscolab

When the settings are needed in the meta.yaml only I think we can patch setup.py then.

Alternative proposal:

(Some) users are used to installing the mss package to get the client (msui). With that background, it would make sense to have the mss package install just msui, and then have separate (sub-)packages for mswms and mscolab. This way, what users are already doing would continue to be the right thing(TM).

Do we have an issue for this split already? I didn't find one.

[ReimarBauer]

It's just important to me that we don't lose the namespace

We don't want to split the repository, because we have many mutual dependencies. Otherwise it usually becomes much smaller than you initially plan. All in all, that's a lot of overhead for the same number of developers.

conda-forge/mss-feedstock#165

On conda-forge each setup.py would need the proper entrypoints, but there it can be patched.

[matrss]

We don't want to split the repository

Agree.

On conda-forge each setup.py would need the proper entrypoints, but there it can be patched.

If the setup.py (or preferably pyproject.toml at some point, since setup.py is more or less obsolete) included the proper entrypoints (for each of the packages in their own configuration file) I don't see how conda-forge would need any patching or care about entrypoints at all. Or does conda-forge not pick up entrypoints from python packages automatically? That would surprise me.

[ReimarBauer]

currently we fetch the tgz of the release. When there is a setup.py and this makes problems we can patch it.
It would not make sense on a splitted package to have entry points which cannot be used. That splitting discussion may continue in the other issue.

setup.py and setuptools is not deprecated for configurations but the command setup.py is.

[matrss]

I am considering getting a v8 release into nixpkgs without running the test suite for now and adding the test suite in when v9 is released and that becomes feasible, but this issue would be a blocker. Since I also consider this to be a proper bug I'll change the milestone to be for the next stable release. The fix should be pretty easy, just moving the entrypoints over into setup.py.

[matrss]

Having the entrypoints in setup.py would also mean that an editable install of the package would behave properly (i.e. msui, mswms, mscolab, etc. would start their development versions).