Dependency freezing for stability when tagging about scores

[tennlee]

So far as I understand it, I think >=1.3.0, ==1.* would be equivalent to ~= 1.3

In order to allow a little backwards compatibility, I think I will manually install some not-quite-latest versions of everything, test them manually, then set ~= those versions on main. I think I'll let develop continue to be unrestricted. That seems like a reasonable way to set out.

[tennlee]

Agreed. This is easy enough to do manually, I will look into the most appropriate method for version 1.

[nikeethr]

Just another comment we should probably use compatible versioning rather than strict equivalence. (i.e. if someone wants to install scores and some other package in the same environment, which has common dependencies.)

In a modular setting one can often switch environments and resume processing, but this would probably be cumbersome, and most users (in my experience) would probably opt to install all their tools in a single environment.

Instead of package==1.0.0, package~=1.0.0 or in environment.yml it might be package="^1.0.0" or similar (again I'm not totally familiar with this and needs to be verified). This is probably equivalent to using a combination of wildcards and comparison operators.

[tennlee]

I agree, some kind of range should be used. The hard part for me is determining the proper ranges and making sure things get tested. I don't think it's straightforward to put every combination of all the dependencies through exhaustive testing. I will do a bit of investigation to see whether or not there are recommended approaches.

[tennlee]

I've looked into some options here. The more precise the approach, the more complex it is to support a wide range of things, particularly if we want complete test coverage of the various combinations. I think if we manually select a suitable version for each of the five minimal dependencies, and use ~= dependency specification, that may provide enough flexibility. People installing fresh will get the latest of everything, but there is at least some flexibility for dependency resolution for people using other packages. I can also put some notes in the installation guide on how we have approached version pinning, and what to do if people find an issue. It seems like most people are worried about breakage caused by being too up-to-date rather than testing old things. I'll put up a pull request and then people can comment on the approach. This isn't something I feel has a clear answer so a few perspectives would probably be helpful.

[nikeethr]

If we were to follow by example: xarray uses only minimum >= requirements https://github.com/pydata/xarray/blob/v2023.10.1/pyproject.toml.

I think I've seen some PEP guideline that backward compatibility needs to be maintained where possible, unless its a major version bump (needs verification). Though there is no way to enforce that, if we stick to well-known packages as dependencies, then I think that ~= makes sense. Effectively if the forzen dependency is 1.x.y, we want >=1.x.y, ==1.* as valid versions. i.e. we don't want to cross-over to version 2 of a dependency without testing.

Note that I don't think all dependencies need to be restricted. For example, in xarray version restriction is a bit tricky, because they use CalVer (something like yyyy.mm.dd). So we may have to use a wider >= and/or we could just let the restrictions on other dependencies like numpy auto-dictate which version needs to be picked.