Is this library still maintained?

[adamjstewart]

It's been almost a year since the last release, and most commits since then have been limited to auto-generated dependabot PRs. The outdated version of timm required to use smp now makes it incompatible with the latest release of lightly: microsoft/torchgeo#1824. PRs to update the version of timm have been ignored (#839), and requests to unpin the timm dependency have been rejected (#620). Our own contributions have been closed, and requests to reopen them have been ignored as well (#776).

Which begs the question: is this library still maintained?

If yes, then it would be incredibly helpful to unpin the timm dependency.

If no, then would you be willing to pass the torch (heh) on to someone else so this incredibly useful library does not become abandoned? Alternatively, does anyone know any alternatives that offer the same functionality and compatibility with modern timm releases as smp?

[WeisiX]

Same question.

[isaaccorley]

I made a fork that is a WIP but will be adding additional features and support and can be installed using pip install torchseg https://github.com/isaaccorley/torchseg

[kpierce8]

my models from a while ago all die at the utils section now. Was moving to torchgeo but now torchgeo is still having issues with this repo. I guess I'll look at torchseg.

[adamjstewart]

TorchGeo may switch to TorchSeg if smp is no longer maintained.

[ogencoglu]

Well analyzed @adamjstewart ! Would be great to hear the verdict on this.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[adamjstewart]

The irony is palpable

[adamjstewart]

@qubvel great to see significant activity on this repo over the last week! However, my question still remains.

TorchGeo is still deciding between depending on (and contributing to) SMP or TorchSeg. We don't really want to maintain TorchSeg if we don't have to, but SMP is missing several things I think we would need for long-term use:

• Multiple maintainers: No one wants to see this repo abandoned. Currently, PR reviews and PyPI releases are bottlenecked by the low bus factor. @isaaccorley and I would be more than happy to help with maintaining this repo if you need help.
• Modern timm support: Newer versions of timm provide significantly improved features and compatibility improvements. Depending on a single outdated version of timm is not possible. Depending on a single (new) version of timm (which will quickly become outdated) is also not possible. We need a range of supported timm versions (preferably without an upper bound)
• ViT backbone support: This is one of the most important features we added to TorchSeg. We tried adding it to SMP (Support Timm ViTs #776), but it was closed. If possible, I would also encourage this repo to remove stalebot, as it closes a lot of important issues and PRs.

If these terms seem reasonable to you, please reach out to us and let us know. We would love to combine forces and either merge the improvements to TorchSeg back into this repo or vice versa.

[qubvel]

@adamjstewart thanks for reaching out! First of all, I apologize a lot for the low activity and for ignoring the library for the last year.. lots of things have happen. But since I am back to open source, I am going to maintain the library again!

Regarding your questions:

• Multiple maintainers: It has to be done. I will be happy to have more than one maintainer to reduce the bus factor, and I would appreciate any help. Probably the repo has to be moved to a personal organization to be able to add collaborators. I am going to explore this question.
• Modern timm support: I am already start working on this :) I saw you have it in torchseg, I came up with something similar.
• ViT backbone support: will be solved with thetimm update also.

More than that, I already have a list of ideas I would like to be implemented!

[adamjstewart]

Awesome, let us know how we can help! I'll close this issue once there are more maintainers, that's probably the biggest threat to maintenance.

[adamjstewart]

@qubvel are there any updates on this? We would like to decide whether to switch TorchGeo to torchseg or stick with SMP in the near future, but I haven't seen any progress on the above points.

[qubvel]

Hi @adamjstewart

1. Regarding timm and vit support, I'm stuck a little bit choosing the best design for it, but hopefully will be done this month.
2. Regarding multiple maintainers, I have not yet come to any solution, but I'm open to any collaboration and open to suggestions in case anyone wants to participate in library development.

[adamjstewart]

1. Is there something wrong with the solution used in torchseg?
2. Like I said, @isaaccorley and I would be happy to help, you just need to add us as collaborators. You can play around with access roles to give us as little or as much permissions as you feel comfortable with and increase it over time as you gain trust. This doesn't require moving the repo to a new organization, although you can later if you want.

[qubvel]

@adamjstewart

1. I like a solution in Torchseg, it looks simple, however, I wish to support more encoders and make it a bit more flexible.. however, that was not as easy as I expected (you can look at this draft PR I made)
2. Thanks for the suggestion, I really appreciate your willingness to help! Personal repo doesn't support collaborator roles, so, I transferred smp to an organization account and invited you to the repo 👍

[adamjstewart]

Awesome, thanks for adding us! I'll let @isaaccorley submit PRs for some of the changes he's already made to TorchSeg and try to review them when I get a chance. I briefly spoke to him about the encoder stuff and I think his decision was made to keep TorchSeg as simple as possible (which is extremely important for maintainability), but at the cost of backwards compatibility (which is also important to avoid upsetting users). We can probably discuss this on GitHub and come up with a good solution together.

Do you have a preferred platform (slack, discord, email) for discussing maintainer questions (e.g., merge policies, release schedules, etc.)? My email is on GitHub and I think @isaaccorley's is also easy to find, but slack might be easier for long-term discussions. That's what we primarily use for TorchGeo.

[qubvel]

@adamjstewart @isaaccorley are you using Discord? I've created a server there, here is a join link https://discord.gg/jWrNZwpB

[patrontheo]

Hey @qubvel @adamjstewart
If I am to choose between smp and torchseg now, which one should I pick ? (which one will be maintained in the long run?)
Thanks

[qubvel]

Hi @patrontheo, we are going to merge torchseg features to smp and continue to maintain smp library!