consider unpinning dependencies?

[Kreijstal]

is it really necessary to depend on scipy==1.15.3 instead of 1.16.1? at least make them forward compatible, that way I do not need to build the dependencis from scratch

[dwash96]

Ahh, I'm not strictly against it. I assume the more popular packages are safe to pin to the requested major version? I think the only issue this creates is knowing when a dependency is not truly sem-versioned and keeping the project up to date with those version ranges. I'll try it though and see what happens.

Is it a specific list of packages you were thinking or just conceptually, how you think the project deps should be managed in general?

[Kreijstal]

Ahh, I'm not strictly against it. I assume the more popular packages are safe to pin to the requested major version? I think the only issue this creates is knowing when a dependency is not truly sem-versioned and keeping the project up to date with those version ranges. I'll try it though and see what happens.

Is it a specific list of packages you were thinking or just conceptually, how you think the project deps should be managed in general?

I believe they shouldn't be pinned.. for a master branch at least, if you want to pin them for a specific release, that makes sense, however you could still soft-pin them, to allow for a variety of other distros..
For example I can tell you aider used to be able to work on archlinux in the past, but for foolish reasons it was not able to be installed anymore, as arch had updated to python 3.13... if you wanted to install aider you had to do it with an older version of python.. and with a virtual environment... look I understand the value of reproducibility as well, you want to make sure your program works and you can't blame external things, but this is sometimes inconsiderate to other people who use different distros, and harms portability, what is the harm with allowing a version a bit higher if it is still compatible? If things break, that is what CI is for! It might be a little work on making things work with new dependencies but it is way easier than porting an old project of many versions to a new one...

Anyway most python projects on pip ecosystem are a bit more lax with their dependencies, so what is the worst thing that can happen, if someone build break, surely they can just solve their problem on their end?

[dwash96]

Fair! I'm currently expanding on your PR's switch to using the requirements.in files instead of the requirements.txt, wherein I am specifying the current version in requirements.txt as the lower bound version and having an uncapped upper bound to just be managed by running the CI pipelines for building and testing to sus out conflicts

[dwash96]

Hey, when you get a chance, would you mind checking if the changes I've just added to the main branch in 0.87.4, work with Arch and Deepseek? I added your changes to the model-settings and metadata files and there should no longer be an upper bound on the python version or any specific library, only lower bounds for what's in requirements.in that match the old version pins

[avneeshs1]

@dwash96 I am not sure if this is related or not but I can't seem to get any version beyond v0.87.3.dev to work.

uv tool install --force --reinstall --managed-python --python python3.12 --with pip --from git+https://github.com/dwash96/aider-ce.git aider-ce && aider-ce --version returns:

Resolved 2 packages in 157ms
Prepared 2 packages in 55ms
Uninstalled 2 packages in 3.15s
Installed 2 packages in 2.68s
 ~ aider-ce==0.87.5.dev3 (from git+https://github.com/dwash96/aider-ce.git@9d94feb5270a7c57039cf9dff58a6c725ef5f560)
 ~ pip==25.2
Installed 2 executables: aider, aider-ce
Traceback (most recent call last):
  File "/home/avneesh.saxena/.local/bin/aider-ce", line 4, in <module>
    from aider.main import main
  File "/home/avneesh.saxena/.local/share/uv/tools/aider-ce/lib/python3.12/site-packages/aider/__init__.py", line 1, in <module>
    from packaging import version
ModuleNotFoundError: No module named 'packaging'

[Kreijstal]

Hey, when you get a chance, would you mind checking if the changes I've just added to the main branch in 0.87.4, work with Arch and Deepseek? I added your changes to the model-settings and metadata files and there should no longer be an upper bound on the python version or any specific library, only lower bounds for what's in requirements.in that match the old version pins

Hi, it works on archlinux but it probably breaks on other distros o.o

[Kreijstal]

No module named 'packaging'

I mean you can use pip install setuptools, packaging, and wheel, no?

[avneeshs1]

@Kreijstal I guess I can but uv install will pick up all the requirements from the setup file. My point is that: uv tool install --force --reinstall --managed-python --python python3.12 --with pip --from git+https://github.com/dwash96/aider-ce.git@v0.87.3.dev aider-ce && aider-ce --version works just fine. So something is busted since v0.87.3.dev release.

[avneeshs1]

I finally found time to diff the versions. I think the change in tool.setuptools.dynamic section from requirements.txt to requirements.in might be the issue. requirements.in is in requirements subfolder and the path should be prefixed?

index 8efec6057..5daab07f2 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -15,7 +15,7 @@ classifiers = [
     "Programming Language :: Python",
     "Topic :: Software Development",
 ]
-requires-python = ">=3.10,<3.13"
+requires-python = ">=3.10"
 dynamic = ["dependencies", "optional-dependencies", "version"]
 
 [project.urls]
@@ -26,13 +26,13 @@ aider = "aider.main:main"
 aider-ce = "aider.main:main"
 
 [tool.setuptools.dynamic]
-dependencies = { file = "requirements.txt" }
+dependencies = { file = "requirements.in" }
 
 [tool.setuptools.dynamic.optional-dependencies]
-dev = { file = "requirements/requirements-dev.txt" }
-help = { file = "requirements/requirements-help.txt" }
-browser = { file = "requirements/requirements-browser.txt" }
-playwright = { file = "requirements/requirements-playwright.txt" }
+dev = { file = "requirements/requirements-dev.in" }
+help = { file = "requirements/requirements-help.in" }
+browser = { file = "requirements/requirements-browser.in" }
+playwright = { file = "requirements/requirements-playwright.in" }
 
 [tool.setuptools]
 include-package-data = true

[Kreijstal]

I finally found time to diff the versions. I think the change in tool.setuptools.dynamic section from requirements.txt to requirements.in might be the issue. requirements.in is in requirements subfolder and the path should be prefixed?

index 8efec6057..5daab07f2 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -15,7 +15,7 @@ classifiers = [
"Programming Language :: Python",
"Topic :: Software Development",
]
-requires-python = ">=3.10,<3.13"
+requires-python = ">=3.10"
dynamic = ["dependencies", "optional-dependencies", "version"]

[project.urls]
@@ -26,13 +26,13 @@ aider = "aider.main:main"
aider-ce = "aider.main:main"

[tool.setuptools.dynamic]
-dependencies = { file = "requirements.txt" }
+dependencies = { file = "requirements.in" }

[tool.setuptools.dynamic.optional-dependencies]
-dev = { file = "requirements/requirements-dev.txt" }
-help = { file = "requirements/requirements-help.txt" }
-browser = { file = "requirements/requirements-browser.txt" }
-playwright = { file = "requirements/requirements-playwright.txt" }
+dev = { file = "requirements/requirements-dev.in" }
+help = { file = "requirements/requirements-help.in" }
+browser = { file = "requirements/requirements-browser.in" }
+playwright = { file = "requirements/requirements-playwright.in" }

[tool.setuptools]
include-package-data = true

you are right it should be requirements/requirements.in instead

[dwash96]

Thank y'all for catching this, about to update it and push it to PyPi shortly