search

singer-io / singer-python

Writes the Singer format from Python
https://singer.io
Apache License 2.0
537 stars 129 forks source link

Loosen version spec in setup.py #80

Closed mplovepop closed 5 years ago

mplovepop commented 5 years ago

https://github.com/singer-io/singer-python/blob/3ddbcc64ddb0763dc8e949afbd6de6eff75e9de7/setup.py#L12

For example, pytz==2018.5 is out. It would be nice to change == to >= for version dependencies. I use pipenv to pin application versions but like to leave library versions looser.

KAllan357 commented 5 years ago

In my experience, I've only ever been hurt by having loose version dependencies. I know this has come up before, but can you point me to anything I can read to help me better understand why this is something the Python community is more comfortable with?

mplovepop commented 5 years ago

It's all just opinions, but I'm persuaded by an article I can't find now, and this stack overflow answer I can: https://stackoverflow.com/a/44938662

In short, pin applications, not libraries. Pinning library dependencies is a world of suffering when multiple libraries have different version dependencies. singer-python is a library so should provide version specs if there are known bad ones, but otherwise it's the application's job to test and pin, e.g. with pip freeze or pipenv. If you want to provide a repeatable known-good set of dependent versions you can provide a requirements.txt file. I think, in short, that dependency management kind of sucks in python!

timvisher commented 5 years ago

Out of curiosity, is there a specific use case that's not working for you right now? Were you hoping to see pytz==2018.5 get pulled in automatically for some reason? Or is this more of a philosophical stance?

timvisher commented 5 years ago

We discussed this internally and I think we're going to come down on the side of maintaining specificity in our version specs. Without a concrete use case we think it's better to make upgrading a manual step rather than assuming that version changes will be ok going forward. That's probably our Maven talking but still it does seem to be the kind of dependency management that makes the most sense to us.

Feel free to reopen this issue if you have a concrete use case to discuss.