I'm questioning whether I should have submitted this PR. If I could get a clear ruling on whether or not the Raspberry Pi organization wants it, I'd appreciate that. If Raspberry Pi doesn't want it, please close the PR.

To be clear: I'm not meaning to be dramatic or sour-grapes about the decision. I'm just looking to keep moving forward. So please let me know. :)

Thanks,
Michael

Very nice rewrite, I will test it soon. I'm usually working on OpenSuse, and I think the clear structure and encapsulation of features makes it easy to port the script to this slightly different flavor of Linux.
I do have some additional feature requests (e.g. I don't like the automated build of the examples), but I will open an issue for that in your repo.

Very nice rewrite, I will test it soon. I'm usually working on OpenSuse, and I think the clear structure and encapsulation of features makes it easy to port the script to this slightly different flavor of Linux.
I do have some additional feature requests (e.g. I don't like the automated build of the examples), but I will open an issue for that in your repo.

Thank you for the kind words and encouragement. 😊

What package manager are you using?

OpenSuse uses its own manager called zypper (this is rpm based). There is a wrapper for apt on the system, this should not be a problem. But package names are usually slightly different.

@michaelstoops this looks really good. Thanks for your hard work. The original was just something I whipped up to stop mistakes when people were following the written instructions. From our point of view, if it's the same as our current script on a Raspbian install (so the documentation doesn't change) then I'm happy to accept it. I would just like to confirm that myself before doing so.

I just tried running this in a Debian docker image, and it got as far as:

Entering phase 0: Preflight check
+ echo 'Verifying sudo access'
Verifying sudo access
+ sudo -v
./pico_setup.sh: line 87: sudo: command not found

I dunno if that's a standard Debian thing, or just a Debian-in-Docker thing? 🤷 I guess at the very least it's probably worth checking if the sudo command is available, and exiting with an appropriate error-message if not?

I dunno if that's a standard Debian thing, or just a Debian-in-Docker thing? 🤷 I guess at the very least it's probably worth checking if the sudo command is available, and exiting with an appropriate error-message if not?

If sudo isn't available then we have bigger problems and should probably just stop?

I side-stepped that problem by doing apt install sudo (Docker images run with the root user by default), and ran the script again, and it ran to completion 👍

I just tried running this in a Debian docker image, and it got as far as:

Entering phase 0: Preflight check
+ echo 'Verifying sudo access'
Verifying sudo access
+ sudo -v
./pico_setup.sh: line 87: sudo: command not found

I dunno if that's a standard Debian thing, or just a Debian-in-Docker thing? 🤷 I guess at the very least it's probably worth checking if the sudo command is available, and exiting with an appropriate error-message if not?

I think Docker images tend to contain as little as possible. What image were you using?

I think Docker images tend to contain as little as possible. What image were you using?

sudo docker run -it debian on my Ubuntu 18.04 x64 laptop.

FYI @michaelstoops msteveb/jimtcl#199

FYI @michaelstoops msteveb/jimtcl#199

Good guy @lurch to the rescue!

Thanks. :)

I think we could support the Debian Docker image, sans sudo, by invoking sudo only if we aren't already root.

I would ask whether we want to go to such trouble to support this image, but it would enable Docker as a platform for automated builds, and I like that idea.

Status update, FYI:

This work is in a testing and test-development phase, which has some long cycles and may take a bit of wall-clock time to complete. I think the core functionality of the setup script is about where it needs to be, so moving on to testing is good progress.

I've re-framed the code that used to be called test/test as a validation process, and have integrated it into the main setup script. I did this because it really was validation of the one build, rather than a test of the code under different circumstances. I figure there's really no reason not to validate every time. Better to know if it's broken.

Testing is critical for a piece of software like this: meant to be run by end-users, working on lots of different platforms, with varying assumptions, and dependent on distinct repos that may or may not have what we expect. Not only do I need to make sure my code works this time, but it will need to be tested again after the next bug fix, the one after that, etc.

In summary, if I don't automate testing, this work will go to waste. Therefore, I'm investing effort in writing a new test suite, which runs this code through all of the supported circumstances for the host it's running on. For example, the setup script should work on bash and zsh, both on the first installation and later updates, etc. The test suite tests those scenarios.

I may or may not automate testing across host types. I am comfortable with spreading these tests out to EC2 instances, but I suspect that most members of this community aren't comfortable with EC2. If there's a more appropriate tool among the potential developers of this code, that might be better. VirtualBox comes to mind, although that isn't particularly convenient for me, running on a MacBook Air M1. None of the virtual host technologies work on M1 as far as I know.

This is all a bit more work than I meant to do, but I think it's a good cause and will make a difference to people. Probably a good piece of work for my portfolio too.

🙂 Michael

Regarding testing, GitHub Actions might be worth considering, because they give us access to Windows, Ubuntu, and macOS hosts, and all for free -- plus, the testing can be fully integrated into the GitHub workflow itself -- when somebody submits a PR, their code will be tested on these platforms automatically. The downside is that the machines are not clean -- they have lots of dev tools preinstalled, but that will still give us some level of validation.

The only platform not covered there would be Raspberry Pi hardware itself. Another option that covers that somewhat would be Docker, which can be used to test Windows, Ubuntu, and Raspbian x86-64 (not sure how close that is to the Pi distros though.) Docker leaves out macOS though.

Personally I'd be happy with an EC2-based solution -- even though the macOS bit is a pain to manage because of the 24-hour minimum -- it's really up to the Pi folks to figure out what would work for them in the long term in terms of maintaining this code, reviewing PRs, and so on.

This is all a bit more work than I meant to do, but I think it's a good cause and will make a difference to people. Probably a good piece of work for my portfolio too.

I think what you're doing is fantastic.

I was thinking about making some radical changes to the setup process myself, but you actually put in the hard work and produced something usable right now. Which is worth a lot more than just ideas.

What were those ideas?

• Ditch the setup completely, instead produce "buildpacks" for the supported platforms. These would be self-contained binary distributions with all the tools you need, packaged along with a snapshot of the relevant SDK & co. repos.
• A Makefile to run the setup, since we're essentially just checking if stuff exists and pulling it down if it doesn't.
• Rewrite the script in PowerShell, so it could run on Windows native, Windows WSL, Linux, macOS, and the Raspberry Pi distros.

Instead of using pushd/popd, you could just run the relevant commands in a subshell (enclose commands in parenthesis ( ... )). This also has the advantage that the commands don't have any unwanted side-effects, e.g. manipulating variables.

But my suggestion is: just merge the pull request. It has been polished more than most of the other stuff for pico. And once that is done, we can have incremental pull-requests for the missing functions/cleanups/etc.

I spent a couple days away from this code. I'm back but I would like to wrap it up.

As discussed, I have moved the validation code into the setup script. test/test_local.sh is now the primary test. I have tested it on Raspberry Pi OS on a Raspberry Pi 4, and Debian and Ubuntu on x85 and Graviton2. I have not tested the current state against macOS because it's expensive and I'd like to do it just once more.

The installer hasn't changed much from earlier revisions, but the testing code is new and I suspect I'll get some feedback on it. Let's do one more round of review, then do the final tests on all the platforms, and then merge the change.

But my suggestion is: just merge the pull request.

I think we were waiting for @liamfraser to run a clean room test to confirm that it performed the same as his original script.

Sorry I disappeared off the radar on this after all my earlier feedback - I had other stuff to work on.
I've just tested this on a fresh Raspberry Pi OS (32-bit) SD-card (running on a Pi400), and it gets as far as:

You must run sudo reboot to finish UART setup
+ validate_uart
+ dpkg-query -s minicom
+ grep -q enable_uart=1 /boot/config.txt
+ grep -q console=serial0 /boot/cmdline.txt

and I only get a pico-sdk directory in ~/pico, with no pico-examples directory. I ran the script again, and it stopped at the same place, and when I cat ~/.profile the export "PICO_SDK_PATH=/home/pi/pico/pico-sdk" line is in there twice! 😕

Perhaps we can use this for testing on macOS? At least for a quick smoke test? https://github.com/sickcodes/Docker-OSX/

@michaelstoops Did you see @lurch's comment?