Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loosen version spec in setup.py #80

Closed
mplovepop opened this issue Oct 17, 2018 · 4 comments
Closed

Loosen version spec in setup.py #80

mplovepop opened this issue Oct 17, 2018 · 4 comments

Comments

@mplovepop
Copy link

install_requires=[

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants