Pin dependencies

[fhenneke]

This pins all dependencies using pip-tools. Depedencies are changed in requirements.in and compiled into requirements.txt via

pip-compile requirements.in

Updating requirements requires pip-tools which can be installed globally via pipx install pip-tools or pip install pip-tools.

I do not know how to test these changes. The tests in the repo are failing without this change and most functionality is not tests at all.

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
pypi/[email protected]	network	0	81.2 kB	bdraco
pypi/[email protected]	environment, eval, filesystem, network, shell, unsafe	0	14.3 MB	Andrew.Svetlov, fafhrd, webknjaz
pypi/[email protected]	filesystem	0	63.6 kB	Andrew.Svetlov, mj
pypi/[email protected]	None	0	64.1 kB	Zac-HD, adriangb
pypi/[email protected]	eval, filesystem, network, shell	0	2.06 MB	AWhetter, BryceGuinta, Claudiu.Popa, ...6 more
pypi/[email protected]	eval, filesystem, unsafe	0	1.31 MB	ilanschnell
pypi/[email protected]	environment, eval, filesystem, shell, unsafe	0	4.93 MB	jtraglia
pypi/[email protected]	environment, eval, filesystem, shell, unsafe	0	9.31 MB	eriknw
pypi/[email protected]	None	0	116 kB	lidatong
pypi/[email protected]	None	0	3.12 MB	tantale
pypi/[email protected]	environment, eval, filesystem, network, shell, unsafe	0	478 kB	mmckerns
pypi/[email protected]	environment, filesystem	0	235 kB	carver, fselmo, kclowes, ...2 more
pypi/[email protected]	environment, filesystem, shell	0	2.2 MB	carver, fselmo, kclowes, ...1 more
pypi/[email protected]	environment, unsafe	0	45.7 kB	carver, fselmo, kclowes, ...2 more
pypi/[email protected]	environment, filesystem	0	49.8 kB	carver, kclowes, pacrob, ...1 more
pypi/[email protected]	environment, filesystem	0	116 kB	carver, kclowes, pacrob, ...1 more
pypi/[email protected]	filesystem	0	24.6 kB	carver, fselmo, kclowes, ...2 more
pypi/[email protected]	filesystem	0	60.8 kB	carver, cburgdorf, fselmo, ...5 more
pypi/[email protected]	environment, eval, filesystem, network, shell, unsafe	0	633 kB	carver, cburgdorf, fselmo, ...5 more
pypi/[email protected]	environment, eval, filesystem, shell, unsafe	0	1.5 MB	Marco.Sulla
pypi/[email protected]	environment, filesystem	0	1.09 MB	Andrew.Svetlov, mj, webknjaz
pypi/[email protected]	None	0	0 B
pypi/[email protected]	filesystem	0	24.3 kB	carver, fselmo, kclowes, ...2 more
pypi/[email protected]	environment, eval, filesystem, network, shell, unsafe	0	870 kB	static, timothycrosley
pypi/[email protected]	environment, eval	0	786 kB	lafrech, sloria
pypi/[email protected]	eval, filesystem	0	36.1 kB	flox
pypi/[email protected]	None	0	0 B
pypi/[email protected]	filesystem	0	22.9 kB	rhgrant10
pypi/[email protected]	environment, eval, filesystem, network, shell, unsafe	0	100 MB	charlesr.harris, matthew.brett, mattip, ...2 more
pypi/[email protected]	eval, filesystem	0	190 kB	erikrose, lonnen, lucaswiman
pypi/[email protected]	filesystem	0	217 kB	cpburnz
pypi/[email protected]	None	0	0 B
pypi/[email protected]	environment, eval, filesystem, network, unsafe	0	9.85 MB	Legrandin

🚮 Removed packages: pypi/[email protected], pypi/[email protected], pypi/[email protected], pypi/[email protected], pypi/[email protected], pypi/[email protected], pypi/[email protected], pypi/[email protected], pypi/[email protected], pypi/[email protected]

View full report↗︎

[bram-vdberg]

Looks good to me, just a small comment about the versioning.

Should we add the information for generating the requirements.txt to the README?

[bram-vdberg]

At the moment this actually removes the version pinning for these packages:

requests==2.31.0
web3==7.0.0
pandas==2.2.1
SQLAlchemy==2.0.28
psycopg2==2.9.9
python-dotenv==1.0.0

If we want to keep them pinned we should add that here. For other packages I think it might be worth pinning major versions as well just because it can't hurt. So for example we could set something like dune-client>=1.7.5,<2.0.

[fhenneke]

Are any of those restrictions necessary at the moment?

I would have expected that one uses as few restrictions as possible in requirements.in. Any recompiling will require some form of testing of the new dependencies anyways. At that stage one can add restrictions or update the code.

Restricting on major versions sounds OK. I would probably only do it after we see an issue with some version.

[harisang]

@bram-vdberg I actually see all these packages you listed fully pinned down in this PR, which i guess is the expected behavior as they are listed in the requirements.in file.

[bram-vdberg]

@harisang I meant that they're pinned in the requirements.txt file, but not in the requirements.in file. This means that recompiling the requirements.in could upgrade these packages. Another way to do this is to pin selected packages in the requirements.in, that means that we can recompile and upgrade downstream dependencies without upgrading these packages.

I think Felix is right that we don't need to do that unless necessary.

[harisang]

Makes sense to me!