Package and add entry point?

HEnquist commented 3 years ago

At the moment the backend is a bunch of files that you uncompress and run with "python /path/to/main.py", with config files stored together with the code. Should we make it a package with an entry point? Then the two config files should probably be merged to one, and not be stored inside the package (but with an example included). The advantage would be that it's easier to run with systemd etc, when you just start it using the entry point:

> camillabackend /path/to/settings.yml

Opinions?

JWahle commented 3 years ago

You mean a python package, that can be installed via pip? What about pycamilladsp and pycamilladsp_plot?

HEnquist commented 3 years ago

As a first step I was thinking of making it a package with setup.py etc, like pycamilladsp and ..-plot already are. Then later they could be published to https://pypi.org/

JWahle commented 3 years ago

Once it is published to pypi, it should be easier to install and update, I guess. What is the advantage, before it is published?

HEnquist commented 3 years ago

That is the question, is there any advantage or is it just different. It would mean the code and all files get installed by pip, and you only have an entry point to start it. Let's say the command is camillaserver. Then you would launch it with a config file as argument, camillaserver myconfig.yml. Mostly just different. @bitkeeper would it matter for moOde? Any preference?

bitkeeper commented 3 years ago

Yes an entry point would be nice. This will indeed improve install and update. Providing the configuration file as argument also makes sense. But it that is the frontend also included in the package ? Only about using custom stylesheet I don't think the location in a package is pratical?

Practice is only that I never have used an official version, always needed some branch or commit haha.

The very fact that guithe -config is a separate file is currently being used:

Currently the gui-config.yml is reloaded without restarting the backend.
By renaming that file from gui-config.yml to gui-config.yml.disabled and visa versa, the expert mode for the camillagui is enabled in the moode gui.

Little bit off topic: Currently I was testing with generating deb files for 6 required cdsp related projects (cdsp, 2x python package, 1x backend+frontend, and alsa_cdsp). This makes it also possible to make sure that the frontend/backend make dep for the correct cdsp version. Generating a deb from a python package is easy.

HEnquist commented 3 years ago

If it's a package then the frontend should be included yes, otherwise it becomes more work to set it up. Not ideal for customizing stylesheets.

That fiddling with renaming the gui-config file is quite ugly, I'm surprised it even works. We definitely need to find a proper way of switching the expert mode.

bitkeeper commented 3 years ago

The suggestion to just rename the gui-config from @JWahle maybe ugly, but in practice is plain easy to implement and use :-) No need to change or parse the content of the config file or restart services. Just a fixed preset what the 'expert mode is'.

bitkeeper commented 3 years ago

After thinking about a python package for the front / backend, I came to the conclusion that I am not going to use the package myself: I have to build things from scratch to:

have to apply a patch
have to add the 'moode' style sheet from @JWahle
supply the correct gui-config for the expert mode
have to add the service script for systemd

It make more sense for me to do that at once pack the stuff as single entity.

That the front- and backend are split projects also doesn't make it easier to build / pack stuff in a single flow.

HEnquist commented 3 years ago

There doesn't seem to be any advantage with packaging, so let's forget that (at least for now).

HEnquist / camillagui-backend

Package and add entry point? #30