Test minimum and maximum supported dependencies

[adamjstewart]

With this PR, we test both the minimum and latest version of all dependencies on every commit. This ensures that the dependencies listed in pyproject.toml actually reflect the true range of supported versions.

Closes #916
Closes #894
Closes #849

[adamjstewart]

It would also be nice to remove pretrainedmodels and efficientnet-pytorch, as both projects were abandoned a long time ago. I think @isaaccorley's fork basically only had deps on timm and torch, which made it really easy to maintain.

[adamjstewart]

How would you feel about getting rid of all non-timm encoders? I think timm has everything pretrainedmodels and efficientnet-pytorch had and more, and it's actually maintained.

[adamjstewart]

Not sure how to debug the segfault issue. Maybe it's time to try to reduce the number of dependencies first.

[qubvel]

Looking through the github I see that most of the repos are using non-timm encoders. While I recommend using timm encoders, I think it's better to leave these dependencies and encoders for backward compatibility.
We can deprecate them and make dependencies optional after that, but I'm not sure it will be good to remove them at all.

[adamjstewart]

Can we at least remove pretrainedmodels? It hasn't been updated in 6 years. The field of deep learning has progressed a lot in 6 years...

[qubvel]

I'm not seeing any problem staying with pretrainedmodels, it's not breaking API because it's not updated and has soft requirements, but of course, we can remove it. A few models depend just on "pretrained_settings" that can be copied, other encoders might be hidden under optional dependency (inception-like, dpn).

[qubvel]

@adamjstewart thanks a lot for working on this! I appreciate your help and efforts to make the library easier to maintain 🙂

[adamjstewart]

I think this is finally ready for review.

Note that these minimum versions are only for the 68% of our code that is covered by our unit tests. The other 32% of our code, or the documentation builds, are not currently tested. We really need to increase test coverage to ensure confidence in these dependency bounds.

[adamjstewart]

We should probably test that newer versions of sphinx and sphinx-book-theme actually work, but this requires #920.

[johnnv1]

instead of hard running it here, what do you think about setting up the https://pre-commit.com/ here, then after you guys set up the https://pre-commit.ci into the repo, so it enables the auto-fix feature on PR's...

[adamjstewart]

I have mixed feelings about this. I like the ability to auto-fix issues, just not auto-commits. I'm on the fence. We haven't enabled this in TorchGeo either.

[johnnv1]

why pin the required? Shouldn't keep it and install the latest version automatically?

[adamjstewart]

This file is only used for CI and is controlled by dependabot. The dependencies used during installation are found in pyproject.toml.

[adamjstewart]

@qubvel is this ready to merge, or are we waiting on additional test coverage?

[yohann84L]

Waiting for timm>=0.9.2, would be great to merge this PR @adamjstewart @qubvel 🥳

[qubvel]

Looks good to, let's merge it!

[brianhou0208]

Hi @qubvel and @adamjstewart,

Thanks to @adamjstewart for contributing to make the library easier to maintain.
I agree that pretrainedmodels and efficientnet-pytorch are quite outdated.
I also agree with @qubvel that keeping these non-timm models doesn’t seem to have any negative impact, and they are relatively stable compared to timm (it hasn't been updated in six years).

Here are some of my thoughts:

• efficientnet-pytorch: I think we can keep this one, as it only depends on torch and is quite clean.
• pretrainedmodels: This repo integrates many classic models, but some of them actually rely on torchvision.
  • VGG, ResNet, DenseNet, etc., we could copy the "pretrained_settings", and we could add new pretrained weights from torchvision (link1, link2).
  • DPN, SENet, Xception, etc., we could reimplement in this repo.
• torchvision: Given the dependency between torch and torchvision, maybe we could add more models like ConvNeXt, EfficientNetV2, etc.

I have attempted to reimplement the DPN model, maybe we can open a new PR to discuss this?

[adamjstewart]

I guess my stance is that just because these libraries are "stable" doesn't mean they are "useful". If the models they implement have now been added to timm, we could use the well-tested timm versions instead, allowing us to greatly simplify SMP. With that said, I don't personally have the time to rip them out and replace them. @isaaccorley did this in TorchSeg, so I'm hoping he can do it here too.

[adamjstewart]

RE: efficientnet-pytorch

I just spent an hour helping a student install SMP on Windows because pip failed when installing efficientnet-pytorch. If efficientnet-pytorch had wheels or used pyproject.toml, this issue would be easy to solve, but it hasn't had a new release in many years and is likely no longer supported. Timm also has efficientnet, efficientnet v2, and many other variants of efficientnet, so why do we need this dependency?

Same for pretrainedmodels and torchvision, all of these backbones are already available in timm. We could streamline installation of SMP by having only a couple dependencies without losing any features.

[brianhou0208]

The comment I provided earlier is just my personal opinion. If needed, I can create a PR to help improve it.

My comment for keeping efficientnet-pytorch is simply because it only depends on PyTorch, without needing any additional packages. As long as it can be installed and run, efficientnet-pytorch should work without any issues.

Of course, torchseg is a great repository—very clean and straightforward. By the way, I also think mmit is excellent.

Ultimately, the final decision rests with @qubvel . I'm just sharing my thoughts. And of course, I also greatly appreciate @adamjstewart previous contributions.