Dependency management and testing

[whaleygeek]

Regarding the ESA ruling on not installing packages on the ISS Astro Pi module, described here:

https://github.com/astro-pi/flight-mp3-examples/blob/master/README.md

Is there an official AstroPi image that is identical to the image installed on the ISS, that people could just download and test against as a known golden reference?

That would be a more traditional engineering technique for people to easily verify that the code they have written does not have any additional hidden dependences.

The general advice from RPi foundation is always to "update your pi regularly' - so I think people are likely to get sucked into a bit of a dependency management nightmare otherwise, and also risk writing code that is not able to be tested in a representative way of the live system (and they won't know it is broken until it is too late).

[whaleygeek]

Also I'm pretty sure on the ISS you have to use import AstroPi, but on latest shipping kit, you have to say import sensehat.

[bennuttall]

It's probably easier for kids to use whatever image they have, and if there are any slight discrepancies, we will fix them. We won't penalise kids for code that works on Jessie, as long as it doesn't depend on anything which is blatantly not available. If in doubt about a package or module, best to ask.

I'm not sure if @davidhoness can provide the flight image or not, but you could always download the last Wheezy image if you wanted to.

[davidhoness]

Hi Dave, if you install the latest Wheezy image, as Ben suggested, and then install only the packages listed in the README, mainly evdev and PIL then you're basically there.

The original Astro Pi python module has been depricated and replaced with the Sense HAT module. The module is backwardly compatible with the old Astro Pi python module by way of an alias.

So where you have:

from astro_pi import AstroPi
ap = AstroPi()

You can just change astro_pi to sense_hat like so:

from sense_hat import AstroPi
ap = AstroPi()

And the rest of your code should just work. We put this in to allow people with large bodies of Astro Pi specific code to easily migrate to the new module. It's also a good way for your code to self describe that it relates to the Astro Pi mission.

[whaleygeek]

Thanks @davidhoness - but do you mean the latest Jessie image, as there are no wheezy downloads from the raspberry pi downloads page any more, as far as I can see? Also, is wheezy installed on the AstroPi flight modules, or Jessie, and which specific release is installed on it?

I also can't see enough from the 'latest release notes' here: http://downloads.raspberrypi.org/raspbian/release_notes.txt to know if the versions of the packages installed on that latest image from the download page, are the same as the versions in your README.md. And if not, what are the instructions for users to 'downgrade' any packages and their dependent modules to the versions that you state in your README?

I know that in practice this might not make much of a difference, (hopefully!) But it doesn't seem too hard to just release the image that was burnt onto the actual AstroPi flight units so that our readers and contributors can do a quick test against the actual version of the platform that their code will run on when up in space on the ISS?

Sorry to be picky here, but I've got far too many grey hairs caused by using the wrong version of a dependent package over the years.

Is there a link to a cached version of the precise image that is installed on the Astro Pi flight modules, that could be used as a final sanity check?

Many thanks.

[whaleygeek]

As a concrete example, you state RPi.GPIO 0.5.11, so does that mean that the latest jessie image we get from the downloads page has these changes below in it, but that the AstroPi flight module does not have these changes in it?

https://pypi.python.org/pypi/RPi.GPIO

0.6.1 Update RPI_INFO to detect more board types Issue 118 - add_event_detect sometimes gives runtime error with unpriv user Issue 120 - setmode() remembers invalid mode

0.6.0a3 Now uses /dev/gpiomem if available to avoid being run as root Fix warnings with pull up/down on pins 3/5 Correct base address on Pi 2 when devicetree is disabled caddr_t error on compile (Issue 109) Error on invalid parameters to setup() (issue 93) Add timeout parameter to wait_for_edge() (issue 91)

[davidhoness]

Hi Dave, I understand your concern but I urge you to not worry about this too much. If there's a compatibility issue we can detect it by testing your entry on Jessie if we see a problem under Wheezy. If it's then selected by the judges we can fix it before it flies into space.

The Wheezy image used on the flight SD cards can be obtained from here; http://downloads.raspberrypi.org/raspbian/images/raspbian-2015-05-07/

This just needs the sense-hat package from apt and evdev from pip and you're basically at parity with the flight SD card image. We can't release that exact image because it will reveal a secret about something coming up later in the mission.

I'm going to add this information to the FAQ though, so thanks for pointing this out.