pinned dependencies

[jf---]

I think not pinning dependencies (scipy==1.1 vs scipy>=1.1) is problematic.

networkx >= 3.0
numpy >= 1.15.4
scipy >= 1.1

for example numpy >= 1.15.4 might imply installing numpy 2.0 with breaking changes / or introducing compatibility issues downstream (I mean related compas_*** packages).
Since compas is a foundational library, dependencies have to be pinned rather than loosely suggested as in the current situation.

modern tools such as pixi offer deterministic builds (via Lock files) which is incredible robust; by that I mean that the requirements.txt deviates too much from the gold standard.

the lack of well defined requirements is seen in some of the best packages in the compas eco system

here compas is a dependency and I think there is a difference in pinning a foundational library vs those that depend on it.

by that I mean that it would be highly productive to refactor requirements.txt across the board.

@tomvanmele & @gonzalocasas curious to have your point of view

[gonzalocasas]

Pinning would also be problematic, but it is true that not having a the upper bound is not safe.
We should use these style of req specifications:

• compatible release (~=) clause. E.g. scipy ~= 1 (equivalent to scipy >= 1.0, ==1.*)
• or just always include an upper bound: scipy >1.1,<2.0

[jf---]

The upper bound limit is more explicit. Should we aim for that @gonzalocasas ?

[gonzalocasas]

Yes, I would say so!

[jf---]

@gonzalocasas start with the compas repo and work our way up from there?