-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Nightly builds possible in Boards Manager #6012
Comments
Hey 😄 ! |
@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 😄 |
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 |
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. |
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: esp8266/Arduino#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
The text was updated successfully, but these errors were encountered: