Version number is out-of-sync with Git code
See original GitHub issueHi,
I’m the maintainer of PyFtdi. I had some hard time figuring out why some reported issues with PyFtdi depicting PyUSB traces did not match at all my own installation of PyUSB. Even after reinstalling from scratch, clearing out pip caches, etc, there were obvious discrepancies between packaged 1.0.2 version available from PyPi and the traces I was reading.
PyUSB has resumed development and that’s really great.
However the version number has not been updated and is still defined as 1.0.2
. Current delta with 1.0.2
is: 30 files changed, 775 insertions(+), 630 deletions(-)
. This is really huge.
It would be nice to add a -dev or any common suffix to the __init__.py
file so that there is no confusion with the active development version and the packaged version on PyPi. I guess PyFtdi will not be the only package which depends on PyUSB and will encounter some maintenance issues to deal with, and confusion is likely to occur.
Note: I used to push PyUSB for the original author (Wander) to PyPi, so if you do not have access yet to PyPi for PyUSB, please contact me.
Thanks.
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
Hi @jonasmalacofilho,
Great 😃 I’ll start working on it as soon as i have some free time and will open a PR where we can discuss further. I have experience with packaging for pypi and conda for all OSes, but so far my experience with packaging deb/rpms/etc. for different Linux distributions is limited to using fpm once. But I’m happy to dive deeper into the topic 👍
Cheers, Andreas
Hi @ap--,
First, I really appreciate you volunteering to do this work! It took me a while to organize my thoughts on this, but here they are:
I really like your solution (even though it won’t be foolproof, because no such thing is possible here),¹ but I see a problem with the extra dependency.
It seems that this may break in systems with old versions of setuptools, one way (toml file) or the other (setup_requires). This would particularly affect Linux distributions packaging PyUSB.
Can you check that stuff like this bug is no longer an issue on any distro versions that would ship a 1.1.0 PyUSB? Besides Debian/Ubuntu, RHEL and CentOS are also likely candidates for problems.
In summary: as long as this is packageable in the major Linux distros, I’m fine with it.
(I think the usual avenues for Windows (manual or Conda) and Mac (Homebrew) should be able to handle this without problems).
On my side, this will also require a bump on the minor version number.
¹ The base version number has some meaning, but the truth is that users may always be running completely random code. Either intentionally or by accident.
For an extreme example, some time ago a company working with mine on a project was having mysterious issues compiling our project. Eventually we figured out that, unknown to them, they were running a completely borked standard library (for the particular language we were using), which even included modules from different major (and totally incompatible) versions of the language! How do you catch this with a version string?