Python package installable from PyPI

[chishm]

First Check

• I used the GitHub search to find a similar requests and didn't find it.
• Checked the tasks tagged issues and verified my feature is not covered

Please provide a concise description of the problem that would be addressed by this feature.

The only current way to install and run Mealie is from the Docker image. I would like to add the ability to install Mealie from Python's Package Index (PyPI), e.g. pip install mealie, and to run it non-containerized, e.g. via a mealie command.

Please provide a concise description of the feature that would resolve your issue.

The tasks required to fully achieve this goal are:

1. Consolidate the frontend and API servers already done in consolidate deployment targets and publish to ghcr.io #2539
2. Create a mealie CLI entry-point feat: Install mealie as CLI command #4323
3. Move the Alembic configuration into the Python package feat: Move alembic config into mealie package for easier distribution #4329
4. Include the frontend source in the Python sdist, include the built static frontend files in the Python wheel
   • Use existing static frontend files when building the wheel, to support the multi-stage Docker build
5. Install the CRF++ model:
   1. Either check for it at app startup and download if missing, or
   2. create a Python package for the CRF++ model too, and make it a dependency of the mealie package
6. Install CRF++ (work begun in mealie-recipes/crfpp#2: Update CRF++ build for 2024):
   1. Either document this as a requirement, or
   2. create a Python package that builds and wraps it
7. Default to storing data in a platform-appropriate location (using the platformdirs package)
8. Build and test a wheel as part of CI
9. Build production Docker image from the Python wheel, for consistency in releases
10. Deploy the wheel to PyPI as part of the GitHub release process
11. Document this installation method, but emphasise that using Docker is the preferred method for most cases

If the Mealie maintainers think this is a worthwhile pursuit, I'm happy to work on all of the above.

Please consider and list out some caveats or tradeoffs made in your design decision

1. CRF++ is not readily available in a Python package. It is also not available from most Linux distribution repositories. I'd have to do some work to make it more easily installable.
2. The CRF++ model is large enough that it shouldn't be included in the main mealie Python package, as it would just add bloat to repeatedly download the same data for every upgrade. It should be installable separately.

Additional Information

• If this is accepted I'm willing to submit a PR to provide this feature
• If this is accepted I'm willing to help maintain this feature
• I'm willing to sponsor/pay a developer to do this work

Edited to add: Testing and documentation tasks, links to associated PRs.

[boc-the-git]

I don't think I see it answered in your post.. why?

[chishm]

Very good question. There's 3 reasons I want this and think it's a good idea:

1. The Docker images can only run on CPUs that they've been published for. At the moment that's AMD64 and ARM64 only. This excludes other platforms, like ARM32 (e.g. older Raspberry Pis) and RISC-V. Python apps can run on anything with a Python interpreter.
2. Docker images add some overhead. A Python package can save a little bit of disk space and RAM.
3. Personally, I like to have systemd directly supervise all of the services I'm running, without containers in between.

[hay-kot]

Worth noting that

At the moment that's AMD64 and ARM64 only

Is because, it won't reliable built on ARM32, moving it to a python package won't fix that, it just pushes the problem somewhere else.

[hay-kot]

Is there a benefit over doing a git clone and manually configuring it to run that way? I understand it's more convenient to install as a python package, but besides convenience, is there a benefit?

[chishm]

Worth noting that

At the moment that's AMD64 and ARM64 only

Is because, it won't reliable built on ARM32, moving it to a python package won't fix that, it just pushes the problem somewhere else.

Indeed, I saw this when looking through the old issues here. AFAICT it's because the CRF++ Docker image that mealie depends on also only supports ARM64 and ARM64. This is something that I also want to fix.

[chishm]

Is there a benefit over doing a git clone and manually configuring it to run that way? I understand it's more convenient to install as a python package, but besides convenience, is there a benefit?

Installing from a wheel means the server running mealie doesn't need all of the development and compilation tools (e.g. poetry and yarn) installed.

Also, a lot of the work needed (tasks 1-7) to get an installable Python package will also help the git clone && yarn generate && poetry install case. In fact, I originally tried to install it this way but found there were many manual steps involved, and that motivated me to bring up this discussion.