Numerical value for 'source-tag' key causes confusing error
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Snapcraft |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
Many projects on github have numerical tags that represent a release version.
The most obvious way to pull a specific revision of something is to use something like 'source-tag: 2.14'.
However, this fails with the message:
'Can't convert 'float' object to str implicitly'
The same snapcraft configuration file works as expected if the tag is enclosed in quotes, but it would be nice to not require the user to put quotes around the tag. It should work perfectly fine to add a call to str() in snapcraft.
Also, if this is something that won't be fixed, then either the error should be caught and a more helpful error message should be displayed, or a stacktrace should be displayed to make it easier to track the issue down.
There is an example snapcraft configuration file attached that demonstrates the bug.
| Wesley Wiedenmeier (wesley-wiedenmeier) wrote | #1 |
| Kyle Fazzari (kyrofa) wrote | #2 |
| Wesley Wiedenmeier (wesley-wiedenmeier) wrote | #3 |
| Kyle Fazzari (kyrofa) wrote | #4 |
| Wesley Wiedenmeier (wesley-wiedenmeier) wrote | #5 |
| Kyle Fazzari (kyrofa) wrote | #6 |
| Changed in snapcraft: | |
| status: | New → Confirmed |
| summary: |
- snapcraft should support numerical values for 'source-tag' key + Numerical values for 'source-tag' key throws exceptions |
| summary: |
- Numerical values for 'source-tag' key throws exceptions + Numerical value for 'source-tag' key causes confusing error |
| tags: | added: yaml |
| 林博仁(Buo-ren, Lin) (buo-ren-lin) wrote | #7 |
Note that `source-tag: 2.14` is implicitly a float in the YAML spec. Even if we converted it to a string after parsing, it would parse `2.10` as `2.1` and so on. You need to tell YAML that it's explicitly a string if you intend for it to be so (by either using quotes as you mentioned or tagging the scalar with !!str).
Snapcraft can implement a custom parser to make this a bit nicer, but I'm a little uncomfortable treating YAML in a non-standard way.