jongracecox / anybadge

A Python project for generating badges for your projects, with a focus on simplicity and flexibility.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ValueError: invalid literal for int() with base 10: '10.00'

llazzaro opened this issue · comments

Today our CI broke with the latest version in pipy.
I saw some fix commits on the repo, not sure if it was published into pipy.

Thanks!

Traceback (most recent call last):
  File "/builds/faradaysec/faraday/faraday_venv/bin/anybadge", line 10, in <module>
    sys.exit(main())
  File "/builds/faradaysec/faraday/faraday_venv/local/lib/python2.7/site-packages/anybadge.py", line 755, in main
    value_format=args.value_format, text_color=args.text_color)
  File "/builds/faradaysec/faraday/faraday_venv/local/lib/python2.7/site-packages/anybadge.py", line 191, in __init__
    value_text = str(self.value_type(value))
ValueError: invalid literal for int() with base 10: '10.00'

I have got the same issue with '10.0' ;)

This was working on 1.4.0. I'm running into the same issue with Friday's 1.5.0 update when passing Pylint output to Anybadge using Bash:

# Retrieve pylint score from log file
score=$(sed -n "s/^Your code has been rated at \([-0-9.]*\)\/.*/\1/p" <<< "$output" || true)

# Round score down (workaround)
score="${score%.*}"

# Create a badge reflecting the score (displayed in pipeline)
anybadge --value="$score" --overwrite --file="$LOG_DIR/pylint.svg" pylint

Can confirm. The error always happens when the decimal places are only zeros (It still works for example with 10.01).

I updated the value_is_int function to return False when there is a . present in the value. This fixes the error.

Here is a badge generated with the fix. This was generated with:

badge = Badge('test', value='10.00')

Note that the zeros are truncated to just 1. Also ignore the black bit - just my lazy screenshot.

image

This did all make me wonder why the value needs to be type-cast at all. If we assumed it was a string then we could just use it as-is. This felt like it could have repercussions, so I would be nervous about making that kind of change.

This is fixed in 1.5.1.

"If we assumed it was a string then we could just use it as-is. This felt like it could have repercussions, so I would be nervous about making that kind of change."

Would this affect the logic for determining a background color based on the numerical value?

Would this affect the logic for determining a background color based on the numerical value?

Ah, I missed the obvious. Yes, it would.