Library.json or library.properties, which one takes precedence

Hello,
I have been looking for a library for a quadrature encoder for STM32 and found Encoder, which has a ton of downloads and seems like a really nice library but I am having issues getting it to work with BlackPill STM32 board.

I did filter the search for STSTM32 and the aforementioned library is the first one offered, so I was surprised when it didn’t work.

At first I thought the issue was that the author was claiming support of all platforms in library.properties since in that file it is marked as "*", but then I found out that in library.json he only claims support for atmelavr and teensy, yet the generated .library.json file shows support for 11 platforms.

Is the library crawler using (what I assume is and Arduino library manifest file) library.properties to generate the dot file instead of the provided library.json?

Am I missing something about the search?

Thanks for help.

library.properties

name=Encoder
version=1.4.1
author=Paul Stoffregen
maintainer=Paul Stoffregen
sentence=Counts quadrature pulses from rotary & linear position encoders.
paragraph=Encoder counts pulses from quadrature encoded signals, which are commonly available from rotary knobs, motor or shaft sensors and other position sensors.
category=Signal Input/Output
url=http://www.pjrc.com/teensy/td_libs_Encoder.html
architectures=*

library.json

{
  "name": "Encoder",
  "keywords": "encoder, signal, pulse",
  "description": "Encoder counts pulses from quadrature encoded signals, which are commonly available from rotary knobs, motor or shaft sensors and other position sensors",
  "repository":
  {
    "type": "git",
    "url": "https://github.com/PaulStoffregen/Encoder.git"
  },
  "frameworks": "arduino",
  "platforms":
  [
    "atmelavr",
    "teensy"
  ]
}

.library.json

{
    "name": "Encoder", 
    "version": "1.4.1", 
    "keywords": [
        "signal", 
        "input", 
        "output"
    ], 
    "description": "Counts quadrature pulses from rotary & linear position encoders.", 
    "frameworks": [
        "arduino"
    ], 
    "platforms": [
        "atmelavr", 
        "atmelsam", 
        "espressif32", 
        "espressif8266", 
        "intel_arc32", 
        "microchippic32", 
        "nordicnrf51", 
        "nordicnrf52", 
        "ststm32", 
        "teensy", 
        "timsp430"
    ], 
    "authors": [
        {
            "email": null, 
            "url": null, 
            "maintainer": true, 
            "name": "Paul Stoffregen"
        }
    ], 
    "repository": {
        "type": "git", 
        "url": "https://github.com/PaulStoffregen/Encoder"
    }, 
    "homepage": "http://www.pjrc.com/teensy/td_libs_Encoder.html", 
    "export": {
        "include": null, 
        "exclude": [
            "extras", 
            "docs", 
            "tests", 
            "test", 
            "*.doxyfile", 
            "*.pdf"
        ]
    }, 
    "id": 129
}
1 Like

I don’t know if there is any order of precedence… it’s more likely the one that is used when registering the library is the one that is used. In this instance, since library.properties is shown as the library manifest, it was probably the one used. This is further reinforced by the library registry showing it supports all the Arduino platforms PlatformIO supports. It’s an unfortunate side effect of library authors just shoving the * wildcard in instead of listing the platforms they have tested the library on, or know it to support.

I hadn’t noticed the .library.json before… presumably it’s partly there to help the library author if they haven’t generated their own library.json by automatically pre-filling fields in that it can. Everything everything in that file does look like it has come from `library.properties or the github repo.

My thought was that .library.json is automatically generated by the crawler.

So IMO there are two issues:

  1. Author is inconsistent in which platforms are supported
    (different values for PlatformIO registry and Arduino library registry)

  2. PIO registry gives precedence to Arduino manifest instead of the PlatformIO one

Yes, crawler generates it with validated data. If there is library.json in a root of library, it will be used instead of library.properties.

1 Like

Isn’t that a problem though?

Sorry, not I understand what you mean. Could you file a bug report here Issues · platformio/platformio-api · GitHub? I think we will drop reading .library.json and stop generate it. I don’t remember why I did it in 2015 year :slight_smile:

1 Like

What I meant is that the library correctly states that it’s not compatible with STM32 but it is listed as compatible because the crawler reads manifest meant for Arduino.

Ok, will file a bug report.