ollama: new port (v0.5.7)

[herbygillot]

Squashed continuation of @rdallman 's PR here: #25274

[i0ntempest]

One more issue I've found after a bit of local testing: you should set <key>Disabled</key><true/> in the launchd script for it to not launch on startup by default, and be consistent with other MP-created ones.

Wouldn't you want it coming up on startup if you intentionally enable the launchd script using port load? The launchd configuration isn't automatically enabled once the port is installed.

If you set <key>Disabled</key><false/> then it is automatically enabled, it's not running right after install but it will be after the next boot. MP installs all agents with <key>Disabled</key><true/>, and then loads/overrides it using a launchd command when the user want it.

[mascguy]

Glad it's building from source. But without listing all of the packages a la go2port, how will those be cached and mirrored by MacPorts? Or is this an Online build, that fetches the packages each time?

Yes, that's correct, it's an online build allowing Go to fetch packages as it normally would each time, a la: go.offline_build no

So why not start with generating the port via go2port, and then add the startup item? Most of the complexity with Make and such doesn't seem necessary.

EDIT: To be fair, Make doesn't add much complexity. Still, it baffles me why this isn't generated by go2port. We completely lose mirroring of packages by MacPorts, which is a key feature.

[mascguy]

Adding @amake for thoughts/comments

[amake]

it baffles me why this isn't a go2port-generated port. We completely lose mirroring of packages by MacPorts, which is a key feature.

I agree with this, which is why I use go2port on all the golang ports I maintain, even when the results needs manual tweaking on every update.

But I have given up trying to get other people to do likewise. It's bad, but golang chose to have a module system that is hostile to our interests, and ultimately us choosing to have online-built ports is, I guess, better than not having the port at all.

[mascguy]

it baffles me why this isn't a go2port-generated port. We completely lose mirroring of packages by MacPorts, which is a key feature.

I agree with this, which is why I use go2port on all the golang ports I maintain, even when the results needs manual tweaking on every update.

But I have given up trying to get other people to do likewise. It's bad, but golang chose to have a module system that is hostile to our interests, and ultimately us choosing to have online-built ports is, I guess, better than not having the port at all.

I definitely want to help you tackle this, via the mod package. (Per our discussion in your repo.) Learning Go has been on my to-do list for a long time, and this is the perfect opportunity!

[herbygillot]

So why not start with generating the port via go2port, and then add the startup item? Most of the complexity with Make and such doesn't seem necessary.

EDIT: To be fair, Make doesn't add much complexity. Still, it baffles me why this isn't generated by go2port. We completely lose mirroring of packages by MacPorts, which is a key feature.

go2port is a great and very useful utility, but it doesn't work very well in a number of situations. I did attempt to generate ollama's Portfile with go2port, ran into issues, and just decided to proceed without it.

That said, this isn't an indictment of the usefulness of go2port.

And if I'm going to proceed the standard Go way, then I'll just use the bundled Makefile so that Go is executed in exactly the way the project intends to execute it.

[mascguy]

So why not start with generating the port via go2port, and then add the startup item? Most of the complexity with Make and such doesn't seem necessary.

EDIT: To be fair, Make doesn't add much complexity. Still, it baffles me why this isn't generated by go2port. We completely lose mirroring of packages by MacPorts, which is a key feature.

go2port is a great and very useful utility, but it doesn't work very well in a number of situations. I did attempt to generate ollama's Portfile with go2port, ran into issues, and just decided to proceed without it.

I'm reasonably certain that we can fix the issues, by updating the code to use the Go lib [for packages]. And that's something I plan to tackle soon, in collaboration with @amake.

So if you aren't in a hurry to merge this, perhaps we can use this port as a test case? In terms of an ETA, I'm hoping to look at it over the next few days.