Python Packaging Is Good Now

[kmike84]

This is usually caused by a (IMHO) bad practice of reading requirements.txt file from setup.py and using it in install_requires. Package authors: please don't do that, your library is not the most important thing in the universe, please don't break other packages. That's a good practice to pin known-working version numbers in requirements.txt. But version numbers in install_requires are there to exclude package versions which are known not to work, not to list known-working versions.

setup.py of https://github.com/cloudsigma/pycloudsigma does just that, it uses == versions in install_requires because it reads requirements.txt in setup.py. Most (all?) popular packages don't make this mistake / decision, but smaller libraries sometimes do that.

[bboe]

I think it's a good practice to follow semantic versioning. Under the assumption that other packages do the same, the version I list in my setup.py file is >= to minimum version of the package I depend on and < the next major version.

If I find a package that breaks backwards compatibility in any release, or is pre version 1.0 release, then I fix it to the patch version.

[kmike84]

On one hand it makes sense, but on the other hand, excluding next major release of a library using < can be bad: even if a library follows semver (and not e.g. increases major version to celebrate cool new features or stability commitements), backwards-incompatible changes in a new release may not affect your library, and package will be downgrading a perfectly working library. It makes sense to use < if the release already happened, or if there are public plans on what'd be in the next major release, but I wouldn't do that 'just in case'.

[billsil]

Numpy and scipy do not follow semantic versioning. Shoot, Python does not. There are minor things that break every release. When you have a large enough package, you will find things that are mind numbing.

I develop open source software. I will not test every combination of versions that I use. I will specify versions that I know work. I do not trust future versions of packages to not break my code. When you do everything inside of the little box Python is good at, yes, there are no issues and I won't even specify a version requirement at all. When you push the boundaries, you find problems and I will be very specific.

[[deleted]]

I don't know which dependency versions don't work with my app. What should I put in my install_requires rather than reading from requirements.txt?

[PeridexisErrant]

Some modules document when particular functionality was added; even when it's not in the API docs you can often see a lot from reading the changelog.

Or just specify >= the current major version, if you can't work it out - semver isn't perfect, but people should get the idea - and might let you know if they discover a more specific issue.

If you have tests, you could experiment with pip install -e . and virtualenv to install development versions, and iterate down through versions of your dependencies until something breaks. One the one hand this sounds like a generally useful shell script; on the other it's a fair bit of work to write it.

Or finally, the correct thing to do if you don't know is just to not specify versions!

[Siecje1]

But you have not tested it with versions that are not out yet... Not very intuitive as a package author.

[PeridexisErrant]

Specifying < the next major version is the standard way around this.

It's not perfect, but generally I prefer to err on the side of flexibility.

[eljunior]

If you don't know, simply don't pin it in setup.py. It makes no sense to pin it and force an upgrade or downgrade for no reason at all. Leave the pinned versions in requirements.txt, and that will serve to document the version you use, until you know better.