chore: mac deployments

[alekst23]

This PR adds support for building and deploy packages on Macs.

The issue arrises because the current build process is configured to build the packages on the local machine, and then copy the package for installation to a Docker image. Doing this on Mac causes the packages to be built for the local Mac architecture, and these file versions do not work in the Docker Linux container.

We address the issue in this PR by moving the build process inside Docker:

• Makefile now copies all required files to the package folder first
• Dockerfile for each package builds the package dependencies and installs the package itself inside the builder layer
• We add an optional ARCH parameter for the make command, which defaults to amd64, and can be set to arm64 for building on Mac
• We add an optional REG_PORT parameter to make, to allow the registry container to change port if 5000 is already taken on the local system

Additional Notes:

• We change lfaiui to leapfrogai-ui in the ui package

[netlify]

✅ Deploy Preview for leapfrogai-docs canceled.

Name	Link
🔨 Latest commit	4554081
🔍 Latest deploy log	https://app.netlify.com/sites/leapfrogai-docs/deploys/6657398b520f080008621648

[alekst23]

I need to test this locally outside docker, but at this point the build and uds deploy should be working on mac.

[YrrepNoj]

One small change request, but other than that this PR is looking good to me!

[YrrepNoj]

@alekst23 Can you update the vllm Maketarget and Dockerfile so that it will conform with the rest of our builds?

I know vllm isn't MacOS compatible so it wasn't in the original scope of what you were doing here, but I think it's important enough to keep our builds consistent.

[YrrepNoj]

The llama-cpp-python Dockerfile was taking a 'shortcut' to see if a model existed in the build/ directory to try to bypass the model-download script. If the build/ directory doesn't exist than our Dockerfile will run into an error when trying to build.

The Dockerfile is trying to do the copy here and the workflow is currently failing because the build/ directory doesn't exist.

I think we can get away with removing this shortcut, but I wouldn't be opposed to just adding another conditional check here either.

[justinthelaw]

Everything, with the exception of @YrrepNoj comments, looks good to me!

Future reference: the copying over of src into the build context's directory is an interesting move to get rid of the relative import within the pyproject.toml. I think a clean-up of these, not just a .gitignore, would be a nice touch to the Makefile. (understanding that this isn't your original pattern, but an already present one)

Thanks for all the testing and improvements!

[gphorvath]

Closing in favor of #659