ollama: add new port for ollama

[rdallman]

Description

This Portfile will install the ollama binary from github releases.

It may be nice to add a start up service that runs the server in the background, which is what brew does too, however this is just the mvp to get something in macports.

• this is my first attempt at writing a portfile and any guidance or nit picking is absolutely welcome and appreciated!

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 14.5 23F79 arm64
Command Line Tools 15.3.0.0.1.1708646388

Verification

Have you

• followed our Commit Message Guidelines?

• squashed and minimized your commits?

• checked that there aren't other open pull requests for the same change?

• checked your Portfile with port lint --nitpick?

• tried existing tests with sudo port test?

• tried a full install with sudo port -vst install?

• tested basic functionality of all binary files?

• checked that the Portfile's most important variants haven't been broken?

[reneeotten]

MacPorts is intended to build packages from source, we do not prefer/want to just install binaries.

Can this be changed so the port is build from source?

[rdallman]

yea, definitely can. it's a little involved, but can give it another whirl - it didn't 'just work' when I tried and it takes quite a long time.

I stole most of my Portfile from https://github.com/macports/macports-ports/blob/master/net/traefik/Portfile which appears to be a binary too so was hoping this was cool now! but all good, thanks for the push. i'll give it a crack.

[pmetzger]

I would love to build ollama in MacPorts from source. It would be a big win.

[rdallman]

@pmetzger would be great! feel free to have at it. I agree it would be nice.

I was going to upload my old version that didn't quite work to go off of for you but I did manage to get a version "working" in a few minutes of fiddling around with that, my results are here: 048f306

the drawbacks I noted on the commit. I can look into this more tomorrow hopefully.

I can't decide the best approach, there seem to be many ways to cut it. the go generate step requires git submodules, thus the git checkout (and I have gotten this 'working' - just the version thing is not working). however, it does seem better to get a tarball from a release and build that, though I have not managed to get that working (even locally, go generate fails, even with some fiddling like git init). I would like to see what kind of magic is required to get ollama -v to return the correct version and go from there, basically.

[rdallman]

release tarballs also have version set to 0.0.0 - I've found the offending file https://github.com/ollama/ollama/blob/main/version/version.go - unclear, seems to be to bless their binaries but I will try to look into the brew script for this when I get a chance maybe they have the sauce

[pmetzger]

Why does this need gcc to build?

[rdallman]

good call. contrary to the developer docs, it doesn't.

[rdallman]

updated with a working ollama --version now, I pretty much copied from homebrew where they find and replace.

underway is making a startup script to run a daemon, getting there, not quite working. i find this package quite odd to use without this in place.

[reneeotten]

please add "github.tarball_from" and set it to appropriate value. If upstream provides them "releases", otherwise "archive". This change will require updating the "checksums" which are currently missing completely.

[reneeotten]

typically also an obfuscated e-mail is provided.

[reneeotten]

this should not be needed I think; removing it will require you to add the "checksums" field.

[reneeotten]

the port is downloading packages in the the build phase, that's not what should happen - we have a fetch phase for that. Perhaps you can use the golang PortGroup and specify the packages. I don't have much experience with it, but perhaps @herbygillot can provide some additional guidance here?!

[pmetzger]

Yah, the golang group is probably the right thing.

[rdallman]

yea good eye thanks. I will play with the golang portgroup, I had no dice the last time due to the issues noted #25274 (comment) about using release zip but should be fine for dependencies.

[rdallman]

thanks @reneeotten for your comments.

I will try to illuminate the main issue(s) with the build process thus far and maybe there is an obvious solution sitting around that I'm missing - I am new to this land! TLDR I've had issues using the release tar / zips, and fetch.type git has solved the woes there - I'd be all about using releases, it seems like the right thing to do, alas, I've had no luck.

I attempted to install from the releases, the mac specific zip (a mac .app - no good for this) and the source code, per the instructions https://github.com/ollama/ollama/blob/main/docs/development.md - namely, there's a go generate ./... before the go build. installing from the unzipped source code doesn't work:

$ go generate ./...
+ set -o pipefail
+ echo 'Starting darwin generate script'
Starting darwin generate script
++ dirname ./gen_darwin.sh
+ source ./gen_common.sh
+ init_vars
+ case "${GOARCH}" in
+ ARCH=arm64
+ LLAMACPP_DIR=../llama.cpp
+ CMAKE_DEFS=
+ CMAKE_TARGETS='--target ollama_llama_server'
+ echo ''
+ grep -- -g
+ CMAKE_DEFS='-DCMAKE_BUILD_TYPE=Release -DLLAMA_SERVER_VERBOSE=off '
+ case $(uname -s) in
++ uname -s
+ LIB_EXT=dylib
+ WHOLE_ARCHIVE=-Wl,-force_load
+ NO_WHOLE_ARCHIVE=
+ GCC_ARCH='-arch arm64'
+ '[' -z '' ']'
+ CMAKE_CUDA_ARCHITECTURES='50;52;61;70;75;80'
+ git_module_setup
+ '[' -n '' ']'
+ '[' -d ../llama.cpp/gguf ']'
+ git submodule init
fatal: not a git repository (or any of the parent directories): .git
llm/generate/generate_darwin.go:3: running "bash": exit status 128

I suppose I could inject something like a git init && git add . && git commit -m "release" - it feels a bit dirty. attempting this doesn't work either, however, though maybe the general spirit would be ok and could go down that route.

attempting go build without the go generate ./... fails as well:

ollama-0.3.6: go build
llm/llm_darwin_arm64.go:8:12: pattern build/darwin/arm64/*/bin/*: no matching files found

that led me to find https://guide.macports.org/#reference.portgroup.github.submodule - which put me on the path to use the git fetch mode and go generate ./... is pleased, allowing go build to work.

let me know if this sparks any ideas!

[rdallman]

same basic issue with using the golang portgroup. vendoring requires not using fetch.type git, and I managed to get the vendored dependencies fetched and all, however at build time the go generate script requires quite a few git commands - maybe someone more familiar knows the right thing to do here wrt getting git to work in go generate from the portfile using the golang portgroup.

[rdallman]

Think I have a reasonable solution to the vendoring and submodules thing to do in the fetch phase. Working out kinks in the start up script and I’ll try to get checksums in too.

[rdallman]

I am waving the white flag on the start up script, have spent a few days of tinkering and I cannot get it working one way or another.

the crux of the issue is that they want a $HOME directory, mostly for storing models in $HOME/.ollama/models, however the config code itself errors out in various other places if a $HOME does not exist. I've tried a few things without any luck to get an MVP (LaunchAgent, making an ollama user, setting OLLAMA_MODELS, possibly others). I couldn't find any examples of other ports with clever workarounds either, perhaps someone more familiar will have ideas. Thanks yall.

[pmetzger]

Okay, so who can help get this over the line?

[i0ntempest]

We could ask upstream to provide a release tarball (with all submodules) starting from the next version. Then the go portgroup could be used.
Whether they want to do that tho is up to them.

[herbygillot]

I took a look at this. Updated to the latest version (0.5.4), switched to archive tarball, and made some changes to the .plist file that are similar to the way we're handling the plist in the prometheus port. We are setting HOME and OLLAMA_MODELS as environment variables in the plist to a path in the MacPorts /var directory.

[herbygillot]

Also, this latest version (v0.5.4), does not look to be using Git submodules. So it's converted to a tarball download.

[rdallman]

@herbygillot thank you! I tested and it works well on my machine too. I am glad they switched from submodules. thanks for your expertise and updating everything.

i suppose it is pretty easy to go in and hack up the plist file or move any existing models around to where they need to go for people that don't want to re-download all of the models, that is my only note. I guess just thinking in terms of notes for people moving from brew install, not sure where to leave such a note. the /var path I get, just thinking for migrating people.

LGTM tho. appreciate it! it's done!

[herbygillot]

I think if someone is moving over from Homebrew, paths not matching will almost usually be a given?

[herbygillot]

Apologies, a mistaken force push against @rdallman's branch caused this PR to close. I'll reopen with @rdallman 's and my commits squashed into one and link back here.

[herbygillot]

#27350