search

stac-utils / pgstac

Schema, functions and a python library for storing and accessing STAC collections and items in PostgreSQL
MIT License
153 stars 39 forks source link

Relax smart-open dependency version #273

Closed mmcfarland closed 5 months ago

mmcfarland commented 5 months ago

In the Rust Hydration PR smart-open went from >=4.2,<7.0", to ==6.3.*. Is this hard pin necessary?

In our specific case, we're looking to use smart-open 6.4, which the old range would have satisfied.

https://github.com/piskvorky/smart_open/releases/tag/v6.4.0

bitner commented 5 months ago

Hmm, not sure why I made that change. I think it was unintentional. I'll test and update.

mmcfarland commented 5 months ago

Thanks @bitner! I don't recall how easy it is to backport changes to releases, but if it's good, could it be made to a 0.8.6 as well as whatever is next for 0.9 (which isn't yet compatible with the latest stac-fastapi.* series)?

bitner commented 5 months ago

Right now we have a hard coded setting that pypgstac needs to be on the same major version as the pgstac that it is working with. The other option is to relax that a bit and allow ranges of pgstac versions that pypgstac can work with so that we could use pypgstac 0.9.1 to work with pgstac 0.8.5.

mmcfarland commented 5 months ago

I think the main challenge is having an option to avoid the breaking changes in 0.9 for now. If we can't get something on the 0.8.x branch probably it's just good enough to know that there's isn't a hard requirement for smart-open and we can just force the dependency version we want somehow.

zstatmanweil commented 5 months ago

I was coming here to write the same issue. Our smart-open is 7.0.4 so if you can make the constraint as relaxed as possible, that would be great. Thank you @bitner !

zstatmanweil commented 5 months ago

hey @bitner, I am on 0.9.0 and am awaiting this change as having a hard time forcing the install with my org's current setup. Any idea when 0.9.1 may be released? If it isn't for a while and it isn't too much work, any chance you would be wiling to cut a release of 0.9.1 with this change?

bitner commented 5 months ago

@zstatmanweil I can cut a 0.9.1, I've got a couple other fixes to get in a release, I'll try to kick out a new release by end of tomorrow.

zstatmanweil commented 5 months ago

Amazing! Thank you so much :)

zstatmanweil commented 5 months ago

Hey @bitner, just following up on this. Do you think a new release still coming soon? Otherwise I am going to have to get creative with my solution :). Thanks!

vincentsarago commented 5 months ago

Hi @zstatmanweil David is off this week so I think the release will only happen next week.

Can installing from GitHub source work for you ?

zstatmanweil commented 5 months ago

Hi @vincentsarago , I can if necessary. I will see if it is released this week and then do that. Thanks!

bitner commented 5 months ago

Sorry @zstatmanweil ! I meant to get things released before going on vacation last week, but things got busy as always. I've just pushed a release to v0.9.1 that has this fix in it.

zstatmanweil commented 5 months ago

@bitner I understand of course! Thanks so much :) I really appreciate it.

zstatmanweil commented 5 months ago

hey @bitner , should I be seeing it as a release? Or is there an additional process behind the scenes? I still see 0.8.6 as the latest

bitner commented 5 months ago

@zstatmanweil I'm seeing it now. It may have taken CI a bit to run to make the release.

zstatmanweil commented 5 months ago

@bitner thanks! It does look like one of the linux builds failed so it never made it to pypi.

bitner commented 5 months ago

Uggh. Don't know what bombed on that run, but when I just kicked those jobs in CI off again, everything went through fine and I'm seeing 0.9.1 up on pypi now. Sorry again for all the rigmarole @zstatmanweil I think that everything should be good to go now