Examples pull wrong component version (PACMAN-1037) #78
Comments
|
See also wolfSSL/wolfssl#8251 |
github-actions
bot
changed the title
|
@gojimmypi could you please add, what does the main/idf_component.yml file of that example look like? Interested in how you are specifying the dependency on wolfSSL component there. |
|
Hi @igrr - thanks for taking a look at this. TLDR: my release I would think (hope) under all circumstances, that when pulling anything other than an explicit preview version (e.g. I think this is what I understand from the Compatible Major Release Clause docs. With the updated version of the component manager, trying to fetch explicit wolfSSL version v5.7.2 in the But instead, the resulting version in the example project The contents in my The respective ExamplesThe contents of and in And so yes, I see that I'm the one that specified the "this version or newer" in the component examples, but in the case where I wanted to test an explicit version, I would have expected that specific version. Perhaps it would be best for me to remove the older preview versions altogether? Do you think it is a best practice that instead of using the |
|
I think it is a reasonable expectation that when an example of a component of a particular version is requested, the example should use the component of that specific version, even though a newer version is available. While it's possible to achieve this behavior by always pinning the dependency version in the examples and updating it in sync with the component version, it makes the release process more complex. |
Yes, I agree. Suggestion: is it possible for the receiving component publisher to scan the incoming source code and enforce this? For example, as I noted above, I incorrectly included a bad component requirement in the respective example While considering inbound processing side, I also suggest enforcing all version text to be lower case. For example, my 5.7.4-Preview1a seems to have ended up with a mix of some instances of
Do you have an example? I would think that simply changing the enclosed example Each enclosed example app vs Thanks again for taking a look at this. Cheers. |
|
Hi @gojimmypi Here I'll explain why and provide a possible workaround. The version solver is picking up preview versions, since preview version is declared in the version spec dependencies:
idf:
version: '>=4.1.0'
wolfssl/wolfssl:
version: ^5.6.6-Stable-Preview1 # <-- hereif you want to pick only released versions, you may update the version spec to dependencies:
idf:
version: '>=4.1.0'
wolfssl/wolfssl:
version: ^5.6.6 # <-- hereand after you call I also agree on the released version shall always be picked first, unless defined |
|
Thanks @hfudev and @igrr - all good suggestions. I've pinned the source code of the examples to a specific published version: The text on the web site would still need to be edited manually, as it has the leading
Component Publish DateHere's another Component Manager curiosity, probably not worthy of an issue of its own: incorrect "updated [n] days ago" text. Just now (lunchtime, Dec 13) I published the wolfSSL 5.7.4-preview1f. However, when visiting that page, there's an indication that it was published 6 days ago:
Note the correct date stamp on the tgz file. I think that prior publish events had an accurate Surely I cannot control that date. A local web server date problem? Binary Size Difference with ESP-IDF v5.3This latest release, I also used ESP-IDF v5.3 instead of 5.2. Note there's a substantial increase in binary size:
|
|
Hi @gojimmypi, thank you for bringing our attention
This is a regression, since refactoring 4 months ago, the date of component creation was frozen on app load, not when a component is created. Because we usually update code quite often, it stayed unnoticed for some time. Fix is made, should be deployed soon.
As the first step to improving the situation, we will change |
|
Hi @kumekay -
sounds great, thank you! How's the staging site doing? I thought my most recent version of wolfSSH preview was working. https://components-staging.espressif.com/components/gojimmypi/mywolfssh/versions/1.4.19-preview1a Now I cannot even add another library such as "esp_jpeg", they all claim to be not found: This is with: |
The Component Manager version
v1.4.1
ESP-IDF Version
v5.2
python Version
3.10.12
Operating System
Windows 11 WSL
Browser (for https://components.espressif.com Issues)
chrome
Description
Specifying an explicit release version of wolfSSL library instead pulls a preview version.
Note the current wolfssl version (as of this issue date) is
5.7.2, but there are several preview versions of5.7.4available:Note that when running
pip install -U idf-component-managerbroke my ability to install the examples:after running the install, the
python -m idf_component_manager --helpno longer reports a version:And after installing an example, another wrong version is installed:
To Reproduce
Change directory into
wolfssl_client.Run
idf.py buildNote the version of wolfSSL pulled is not the release
5.7.2specified, rather the most recent preview version:5.7.4-preview1e:gojimmypi:/mnt/c/test/component
$ idf.py create-project-from-example "wolfssl/wolfssl=5.7.2:wolfssl_client"
Executing action: create-project-from-example
Example "wolfssl_client" successfully downloaded to /mnt/c/test/component/wolfssl_client
Done
gojimmypi:/mnt/c/test/component
$ cd wolfssl_client
gojimmypi:/mnt/c/test/component/wolfssl_client
$ idf.py build
Executing action: all (aliases: build)
Running cmake in directory /mnt/c/test/component/wolfssl_client/build
Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DPYTHON=/home/gojimmypi/.espressif/python_env/idf5.2_py3.10_env/bin/python -DESP_PLATFORM=1 -DCCACHE_ENABLE=0 /mnt/c/test/component/wolfssl_client"...
-- No conflicting wolfSSL components found.
-- IDF_TARGET not set, using default target: esp32
-- Found Git: /usr/bin/git (found version "2.34.1")
Detected UNIX
Detected WSL
Detected Linux
Found PROTOCOL_EXAMPLES_DIR=/mnt/c/SysGCC/esp32/esp-idf/v5.2/examples/common_components/protocol_examples_common
Found PROTOCOL_EXAMPLES_DIR=/mnt/c/SysGCC/esp32/esp-idf/v5.2/examples/common_components/protocol_examples_common
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/gojimmypi/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/gojimmypi/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/gojimmypi/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32-elf-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- git rev-parse returned 'fatal: not a git repository (or any parent up to mount point /mnt)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).'
-- Could not use 'git describe' to determine PROJECT_VER.
-- Building ESP-IDF components for target esp32
Dependencies lock doesn't exist, solving dependencies.
..Updating lock file at /mnt/c/test/component/wolfssl_client/dependencies.lock
Processing 2 dependencies:
[1/2] idf (5.2.0)
[2/2] wolfssl/wolfssl (5.7.4-preview1e)
-- Begin wolfssl
The text was updated successfully, but these errors were encountered: