Please allow dependencies by ranges

[comtom]

For projects that depend on the libraries that bitconlib uses, it is very possible that there are conflicting dependencies causing the project to fail to install. With pip install usually it only prints a warning in the terminal, but if the main project uses pipenv or poetry such a conflict will prevent to install any dependency.

Reason of this issue is in setup.py. Instead of:

install_requires = [
      'requests==2.26.0',
      'fastecdsa==2.2.3;platform_system!="Windows"',
      'ecdsa==0.16;platform_system=="Windows"',
      'pyaes==1.6.1',
      'scrypt==0.8.19',
      'SQLAlchemy==1.4.28',
      'numpy==1.19.5;python_version<"3.8"',
      'numpy==1.21.4;python_version>="3.8"'
]

can be

install_requires = [
      'requests>=2.0.0,<3.0.0',
      'fastecdsa>=2.0.0,<3.0.0;platform_system!="Windows"',
      'ecdsa>=0.12,<0.17;platform_system=="Windows"',
      'pyaes>=1.5.0,<1.7.0',
      'scrypt>=0.8.1,<0.9.0',
      'SQLAlchemy>=1.3.0,<1.5.0',
      'numpy>=1.18.0,<1.19.6;python_version<"3.8"',
      'numpy>=1.21.0,<1.25;python_version>="3.8"'
]

These ranges should be replaced too in requirements.txt

[mccwdev]

That is a good point, I understand the problem with conflicting dependencies.

But the library is extensively tested with those specific versions, and it's not possible to test for large versions ranges of packages and all combinations. So I'm not sure how to solve this, maybe use smaller version ranges and only for specific packages?

[comtom]

thanks, in my case I would need to relax ecdsa, SQLAlchemy and numpy requirements a little bit. I I agree that the example I provided may be too relaxed, but was just to name an example, as a general rule, when there is a breaking change a library should increase their major version number. Although I understand that is still necessary to test, should be "safe" for most cases.

[mccwdev]

In commit https://github.com/1200wd/bitcoinlib/commit/8324ef3d2c6d28ebaca15fed480cf205e29c0526 minimum package requirements are used instead of fixed version numbers. Tests with the first and latest version for are packages are succesful.

Does this work for you?

[comtom]

yes it does. I recommend using a limit for new major versions. usually a new major release will have breaking changes. For instance if SQLAlchemy is updated to 2.0.1 it may break this library. one option could be using: SQLAlchemy==1.4.x

or

SQLAlchemy~=1.4