Open me-no-dev opened 7 years ago
Hey :smile: !
I believe that @ffissore intention was to use the nightly
json as a sort of continuous integration channel, so the version number must be fixed.
All the problem are due to the fact that the board manager ignores a core folder if it's not reference anywhere, and this happens continuously with the nighlty json.
https://github.com/arduino/arduino-builder/pull/84 could mitigate (not solve) this issue but the best policy is still to use a fixed version number
@facchinm the way I see it, package manager should detect other versions of the hardware that might be already present and clean them up (upon user confirmation maybe) before installing the new version selected. You show in the PR above that it is possible to detect such folders :) so how about I look into Package Manger and implement it? Could there be any bad side effects?
Detect/delete actions should be taken during core installation, so not in builder territory (so pr#84 doesn't apply). The right place to perform this check is https://github.com/arduino/Arduino/blob/master/arduino-core/src/cc/arduino/contributions/packages/ContributionInstaller.java#L161 . There could be some problem if the core we are going to forcefully remove references other (unused) tools, but it's another story :smile:
Thanks for the clarification. I guess I will have to stick with a fixed version number for now, but it does feel a bit like a hack. Different users with different nightly versions will see the same '2.4.0-nightly' installed in the board manager.
Still, I think it would be nice for board manager / (or arduino-builder) to hande the concept of versions which once used to be available, but can no longer be installed, and as such, are removed from the package json file. Currently if I remove any legacy version from the package json file, users who still have it will get the "board esp8266 package esp8266 is unknown" error.
If handling of such "versions which are no longer available in the package" is implemented, this would also solve the nightly package issue. In this case I wouldn't even need to use the "nightly" feature of the IDE specifically, I can just as well add size and checksum values to the nightly version.
Edit: haven't refreshed the page to get your latest reply before sending this. Good point about the tools. As we don't share any tools with other cores I didn't think of this, but it's probably an issue which may very well happen for AVR and ARM cores.
@facchinm thanks for the pointer! Will do some reading and some testing :) I have some ARM stuff here, so can test the unused tools concept as well. Will report on any progress :)
@facchinm @igrr if we remove folders of the same platform to replace it with newer one, what are the chances that you could end up with unused tool? even if it's ARM, external tool is the toolchain, which will still be used/updated with the new package. Unless it's some weird situation where a board developer made a tool external for no reason, then abandoned it, I don't think we can hit that situation.
@me-no-dev apart from the abandoned tool situation, which is quite unusual, I was thinking about a "nightly" platform which requires toolX
version 1.0
, gets removed and replaced by one which requires toolX
version 1.1
.
In this case, since both the folders are still there, if you reference program.tool=toolX
without any version from platform.txt
, the builder could end up selecting the older tool
If I understand well, the board manager should be able to understand that an already installed board whose definition has disappeared from the package.json is still usable and upgradable. Any update ?
No news on this side, if a platform (or referenced tool) installed via package_index.json disappears the builder is still unable to find it (since the directory structure shadows the json content). In case you use $sketchbook/hardware, instead, everything is self contained and discovered at runtime.
Hey guys! @igrr was investigating the possibility to have nightly packages for the ESP8266 and ESP32 and found out that it is currently a bad idea/not possible. Here is a link to the issue on our side: https://github.com/esp8266/Arduino/pull/2936 Do you guys have any ideas how we can do that? I do not mind putting the time to modify and PR any changes required to the package manager, but I am not intimate with the code yet and do not really know how it works. Basically I'm asking if we can make the package manager figure out that there are earlier versions of given package based on the folder name or package manifest, rather than expecting to have the information for it in the new manifest