Relax the versioning

[JudithBernett]

I was speaking with some of the Bioconda maintainers, and they commented on my Bioconda recipe, suggesting that it is better practice not to cap the versions and rely on someone manually bumping them. Instead, they believe it is better to address version-related problems as they arise. I was trying to do that for drevalpy, but because we have curve-curator as a dependency, I could, e.g., not bump to Python 3.14.

What do you think about uncapping the versions? So, instead of:

curve_curator/pyproject.toml

Lines 10 to 21 in 71e46f7

	python = ">=3.11,<3.14"
	bokeh = ">=3.4.0,<3.8.0"
	numpy = ">=1.25.0,<3.0"
	pandas = "^2.1.0"
	scipy = "^1.10.1"
	statsmodels = "^0.14.0"
	tqdm = "^4.66.1"
	pytest = "^7.4.3"
	[tool.poetry.group.dev.dependencies]
	seaborn = "^0.12.2"
	pytest-cov = "^4.1.0"

it would become

python = ">=3.11" 
 bokeh = ">=3.4.0" 
 numpy = ">=1.25.0" 
 pandas = ">=2.1.0" 
 scipy = ">=1.10.1" 
 statsmodels = ">=0.14.0" 
 tqdm = ">=4.66.1" 
 pytest = ">=7.4.3" 
  
 [tool.poetry.group.dev.dependencies] 
 seaborn = ">=0.12.2" 
 pytest-cov = ">=4.1.0" 

[FloBay]

Hey Judith,

I am in principle fine and partially annoyed by tqdm because of exactly that situation (which is caped to python 3.12) that no-one is updating it since 1.5 years. I am even thinking of switching to a different progress bar system, but I have had not enough time atm to actually implement it.

Only with bokeh, I am a bit hesitant to relax it. The dashboard code is super deep in the javascript of bokeh and typically something always breaks with every 3.x update. So my strategy was sofar to be quite strict with bokeh versioning. Because for most non-bioinformations all of this versioning is beyond the scope they should ever worry about. It must just work with one command.

I can relax this with the next version that hope fully is pushed soon from the development branch.

@MatthewThe opinions?