aider
aider copied to clipboard
add FreeBSD installation using ports
NB package builders take 3-5 days to have binaries available for users.
Who is building the py-aider-chat package?
Strictly speaking it's done automatically within the official FreeBSD port builder cluster. The person who is updating or patching the port is me.
you can see the git history here: https://cgit.freebsd.org/ports/log/misc/py-aider-chat and what versions are available from packages here https://freshports.org/misc/py-aider-chat on various architectures and people can log bugs here https://bugs.freebsd.org/bugzilla/ if they think its a packaging/port problem, or obviously for real aider bugs here or discord makes more sense.
I probably can't link to this from the install docs unless there's a mechanism to automatically update the port when aider releases a new version? I worry about sending users to install from places which might go stale.
I'd happily accept a PR which automated that.
fair enough. The FreeBSD distribution ethos (a single shared ports tree, all packages built from source, not container packaging) means that each update needs human oversight of the changes, as we share a number of python dependencies with other packages too.
aider is at 0.55.0 atm and I'm updating to 0.56.0 already. hard to keep up!
I see the runtime dependencies on https://www.freshports.org/misc/py-aider-chat all have version specifiers like > or >=, rather than the specific pinned dependencies listed in aider's requirements.txt file. Is the port really installing packages according to these loose constraints?
Runtime dependencies:
py311-arrow>0 : devel/py-arrow@py311
...
py311-jsonschema>=0 : devel/py-jsonschema@py311
...
py311-litellm>=1.24.5 : misc/py-litellm@py311
...
In particular, packages with pinned versions noted at the end of aider's requirements.in file are hard requirements. These versions are pinned because aider is known not to work with the latest versions of these libraries.
I see the runtime dependencies on https://www.freshports.org/misc/py-aider-chat all have version specifiers like
>or>=, rather than the specific pinned dependencies listed in aider's requirements.txt file. Is the port really installing packages according to these loose constraints?
TLDR, yes but not quite. You can skip the longer overview below, but I hope it helps clarify how stuff works in FreeBSD ports tree.
I suggest (for aider on FreeBSD) we start with a PR that lists the
compiler dependencies, to be able to pipx install .. - this would be
slow-changing and stable components - rust, fortran, gcc, cmake,
meson, ninja, python3.11, pipx, numpy (1.26.4 now) & scipy (1.11 now).
This will give users clear install steps, and still let aider use its own specific constraints. But they won't have a turn-key "pkg install py-aider-chat" experience that ports & packages offers, and building from sources is quite slow.
ports tree
we have two branches of the ports tree - quarterly, which is
what most users will use, updated every quarter, from latest
branch. This is where ports get tested & updated, it moves quite
fast, and sometimes there is breakage, where 2 different tools
require a dependency but there is no single mutually compatible
version. e.g. between July & August, some of aider's dependencies
moved to incompatible versions, compared to requirements.in.
In a docker container, you'd rely on pip to pull in precisely the versions you want, based on requirements.txt. Thus each tool may bring its own python, a specific version of a JSON parser, have a ceiling version of scipy, etc.
But wthin the ports tree, we are sharing all dependencies across many many applications - from py-qt5, to ansible, django, and ofc aider too.
runtime deps
TLDR, yes but not quite. These are the constraints that the ports system will enforce and build & runtime it doesn't mean it will have latest versions on pypi.org, for example, only the latest version of that dependency that's already in the ports tree. Many of these dependencies aren't maintained by me directly.
My 0.56.0 commit will make these more explicit, but normally this
isn't really necessary for most ports - same as in requirements.in
you don't pin httpx or requests typically.
We (try to) avoid having multiple versions of various packages, and instead find and fix bugs where we can, or be less constrained for various packages if that's sufficient. Typically end users do report bugs in FreeBSD's bug tracker, as a consequence of this.
Sometimes there is no possible solution that meets all packages, or its not possible to port a dependency, or like tokenizer, it breaks for some ports and not others.
aider on FreeBSD
For aider on FreeBSD, there's no playwright, so I have a small local patch to use httpx directly, and skip even searching for playwright. We don't have google's generative AI library, and so that will fail at runtime unless somebody does the work to port all of that google code - I'm not motivated to do that.
Many of the ports are maintained by different people, and some core python ports are maintained by a specific python team - that's not me, I'm not a python expert, just a consumer.
Practically, each aider version change is built & tested manually. before I push any commits to the public ports tree. I test with anthropic & openai, so obvious issues will turn up quickly, but subtle ones clearly won't.
Regarding installing from sources/pip/pipx, to put things into perspective, I've spent ~ 9 hours now trying to install aider via pip/pipx without success - 3x more than doing the original porting effort.
Building numpy, scipy, etc from sources is not a great user experience, so I'd like to fix both the install-from-git as mentioned in my last comment, and use that as a reference to improve the port next.
I understand the need to tightly couple dependencies, especially in fast-moving projects, but I'm hopeful we can find a way to do this, aider is such an amazing project! :1st_place_medal:
I was unable to build solely from pipx, I will close this PR and continue that discussion in discord.