dearwolf/aider
1
0
Fork 0
mirror of https://github.com/Aider-AI/aider.git synced 2025-05-28 16:25:00 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
aider is AI pair programming in your terminal https://aider.chat/
10666 commits 2 branches 241 tags 263 MiB
Find a file
Claudia Pellegrino 31c4198cee
fix: let fewer conflicts occur across requirements 
**tl;dr** Introduce a common umbrella constraints file (that works
across requirement extras) to avoid package version conflicts and
to reduce the need for manual pinning in `*.in` files.

Previously, spurious package version conflicts could sometimes occur
across requirements for `pip install -e .`, `pip install -e .[help]`,
`pip install -e .[playwright]`, and so on. Here’s why:

- There are five different requirement configs: the set of base
  requirements (`requirements.txt`) and four additional requirement sets\
  (aka "extras"): `dev`, `help`, `browser`, and `playwright`.

- Each of those five configurations spans its own tree of dependencies
  [1]. Those five trees can slightly overlap. (For example, `greenlet`
  is a transitive requirement for both the `help` and `playwright`
  trees, respectively.)

- If you want to resolve those dependency trees so you get concrete
  version numbers, you can’t just look at each tree independently.
  This is because when trees overlap, they sometimes pull in the same
  package for different reasons, respectively, and maybe with different
  version constraints.
  For example, the `help` tree pulls in `greenlet`, because `sqlalchemy`
  requires it. At the same time, the `playwright` tree also pulls in
  `greenlet` because it’s needed by the `playwright` package.
  Resolving those constraints strictly individually (i.e., per tree) is
  usually a mistake. It may work for a while, but occasionally you’re
  going to end up with two conflicting versions of the same package.

To prevent those version conflicts from occurring, the five
`pip-compile` invocations were designed as a chain.
The process starts at the smallest tree (i.e., the base
`requirements.in` file). It calculates the version numbers for the tree,
remembers the result, and feeds it into the calculation of the next
tree.

The chain design somewhat helped mitigate conflicts, but not always.
The reason for that is that the chain works like a greedy algorithm:
once a decision has been made for a given package in a tree, that
decision is immediately final, and the compilation process isn’t allowed
to go back and change that decision if it learns new information.
New information comes in all the time, because larger trees usually have
more complex constraints than smaller trees, and the process visits
larger trees later, facing additional constraints as it hops from tree
to tree. Sometimes it bumps into a new constraint against a package for
which it has already made a decision earlier (i.e., it has pinned the
concrete version number in the `requirements*.txt` file of an earlier
tree).

That’s why the greedy chain-based method, even though it mostly works
just fine, can never avoid spurious conflicts entirely.
To help mitigate those conflicts, pinning entries were manually added to
`requirements.in` files on a case-by-case basis as conflicts occurred.
Those entries can make the file difficult to reason about, and they must
be kept in sync manually as packages get upgraded. That’s a maintenance
burden.

Turning the chain into an umbrella may help. Instead of hopping from
tree to tree, look at the entire forest at once, calculate all the
concrete version numbers for all trees in one fell swoop, and save the
results in a common, all-encompassing umbrella file.

Armed with the umbrella file (called `common-constraints.txt`), visit
each tree (in any order – it no longer matters) and feed it just the
umbrella file as a constraint, along with its own `*.in` file as the
input.
Chaining is no longer necessary, because the umbrella file already
contains all version constraints for all the packages one tree could
possibly need, and then some.

This technique should reduce manual pinning inside `*.in` files, and
makes sure that computed version numbers no longer contradict each other
across trees.

[1]: From a graph theory point of view, I’m being blatantly incorrect
here; those dependency graphs are usually not trees, because they have
cycles. I’m still going to call them "trees" for the sake of this
discussion, because the word "tree" feels less abstract and intimidating
and hopefully more relatable.
2025-03-02 02:50:03 +01:00
.github ci: Update GitHub Actions workflow to use github.event_name for build conditions 2025-01-16 11:52:34 -08:00
aider pricing 2025-02-27 14:34:47 -08:00
benchmark refactor: Update problem_stats.py to use polyglot_leaderboard.yml 2025-02-27 08:56:54 -08:00
docker build: Add boto3 to Dockerfile pip install commands 2025-02-04 12:52:05 -08:00
requirements fix: let fewer conflicts occur across requirements 2025-03-02 02:50:03 +01:00
scripts fix: let fewer conflicts occur across requirements 2025-03-02 02:50:03 +01:00
tests test: Update sonnet model name in test_models.py 2025-02-24 12:32:47 -08:00
.dockerignore prep docker build to run in github action 2023-10-18 08:45:02 -07:00
.flake8 removed punctuation ignores 2024-07-13 07:47:36 +01:00
.gitignore feat: Fix Go installation for Apple Silicon and add tmp.benchmarks to gitignore 2024-12-24 17:30:41 +00:00
.pre-commit-config.yaml chore: configure codespell to use pyproject.toml and skip specific files 2024-09-10 13:37:18 -07:00
CNAME Create CNAME 2023-05-15 12:54:06 -07:00
CONTRIBUTING.md copy 2025-01-09 09:56:49 -08:00
HISTORY.md copy 2025-02-26 09:05:46 -08:00
LICENSE.txt Added Apache 2.0 license 2023-05-15 08:29:00 -07:00
MANIFEST.in copy 2024-12-16 15:57:13 -08:00
pyproject.toml cleanup cog of toml 2024-12-16 12:08:08 -08:00
pytest.ini ci: remove redundant AIDER_ANALYTICS_LOG environment variable 2024-11-30 11:37:33 -08:00
README.md copy 2025-02-08 06:49:14 -08:00
requirements.txt fix: let fewer conflicts occur across requirements 2025-03-02 02:50:03 +01:00

README.md

Aider is AI pair programming in your terminal

Aider lets you pair program with LLMs, to edit code in your local git repository. Start a new project or work with an existing code base. Aider works best with Claude 3.5 Sonnet, DeepSeek R1 & Chat V3, OpenAI o1, o3-mini & GPT-4o. Aider can connect to almost any LLM, including local models.

aider screencast

Getting started

If you already have python 3.8-3.13 installed, you can get started quickly like this:

python -m pip install aider-install
aider-install

# Change directory into your code base
cd /to/your/project

# Work with DeepSeek via DeepSeek's API
aider --model deepseek --api-key deepseek=your-key-goes-here

# Work with Claude 3.5 Sonnet via Anthropic's API
aider --model sonnet --api-key anthropic=your-key-goes-here

# Work with GPT-4o via OpenAI's API
aider --model gpt-4o --api-key openai=your-key-goes-here

# Work with Sonnet via OpenRouter's API
aider --model openrouter/anthropic/claude-3.5-sonnet --api-key openrouter=your-key-goes-here

# Work with DeepSeek via OpenRouter's API
aider --model openrouter/deepseek/deepseek-chat --api-key openrouter=your-key-goes-here

See the installation instructions and usage documentation for more details.

Features

Top tier performance

Aider has one of the top scores on SWE Bench. SWE Bench is a challenging software engineering benchmark where aider solved real GitHub issues from popular open source projects like django, scikitlearn, matplotlib, etc.

More info

Kind words from users

  • The best free open source AI coding assistant. -- IndyDevDan
  • The best AI coding assistant so far. -- Matthew Berman
  • Aider ... has easily quadrupled my coding productivity. -- SOLAR_FIELDS
  • It's a cool workflow... Aider's ergonomics are perfect for me. -- qup
  • It's really like having your senior developer live right in your Git repo - truly amazing! -- rappster
  • What an amazing tool. It's incredible. -- valyagolev
  • Aider is such an astounding thing! -- cgrothaus
  • It was WAY faster than I would be getting off the ground and making the first few working versions. -- Daniel Feldman
  • THANK YOU for Aider! It really feels like a glimpse into the future of coding. -- derwiki
  • It's just amazing. It is freeing me to do things I felt were out my comfort zone before. -- Dougie
  • This project is stellar. -- funkytaco
  • Amazing project, definitely the best AI coding assistant I've used. -- joshuavial
  • I absolutely love using Aider ... It makes software development feel so much lighter as an experience. -- principalideal0
  • I have been recovering from multiple shoulder surgeries ... and have used aider extensively. It has allowed me to continue productivity. -- codeninja
  • I am an aider addict. I'm getting so much more work done, but in less time. -- dandandan
  • After wasting $100 on tokens trying to find something better, I'm back to Aider. It blows everything else out of the water hands down, there's no competition whatsoever. -- SystemSculpt
  • Aider is amazing, coupled with Sonnet 3.5 it’s quite mind blowing. -- Josh Dingus
  • Hands down, this is the best AI coding assistant tool so far. -- IndyDevDan
  • [Aider] changed my daily coding workflows. It's mind-blowing how a single Python application can change your life. -- maledorak
  • Best agent for actual dev work in existing codebases. -- Nick Dobos