In CircuitPython mode, Mu should allow users to save their files off-device for SCM.

[ntoll]

This discussion is a result of the work by @fmorton in PR #485. The problem we're trying to solve is:

• CircuitPython source code is stored on the device, usually as code.py.
• Often, it is desirable for users (students?) to have a copy of their code on their development machine. Why? In a classroom situation students don't often find themselves re-using exactly the same device from lesson-to-lesson.
• Mu should address this in some way as an opportunity for folks to learn about SCM (source control management).
• Furthermore, it's important that students have some way to name their local version of the file (so they can tell what it's for). The convention of code.py is from CircuitPython and is needed so the device knows what code to run on boot (hence the obvious name). This need not be the case for the file when stored on the user's local (non-device) file system.

Proposed solutions (based on @carlosperate's summary in the recent video call):

• Do nothing - this becomes a teaching and learning problem for teachers who need to explain how to do healthy SCM.
• Update the "Save" button such that it copies the current file in two ways:
  • As code.py on the attached CP device.
  • As user_defined_name.py in a circuitpython directory within the user's mu_code directory.
  • If no device is currently attached, only the user_defined_name.py file is saved.
• Add a new "Run" button (whose visibility can be changed via the admin pane). The current "Save" button saves the file to the local filesystem, the new "Run" button copies this file onto the attached CircuitPython device. Essentially the two steps in the 2nd suggestion are split out into two buttons.

cc/ @tannewt @kattni @makermelissa @DaveSprague

[tannewt]

I think you could also simply backup to the host device with timestamped versions of the file. For example: 20210224-code.py It matches the very most basic version of versioning which simply stores multiple copies of a file across time.

[ntoll]

Yeah... I wondered about a timestamp in the name too.

[carlosperate]

Yeah, for the Save button change option this sounds like the simplest way to present it to the user.
In this case, to avoid having hundreds of files we could overwrite the same file "per session". So every time Mu starts, or code.py is opened, it would create a new file and then overwrite it with the latest timestamp.

Perhaps it doesn't quite fit the most common way to manage files in version control, but it's still an improvement.

[carlosperate]

Great summary, thanks Nicholas! And also thanks to everybody else in the discussion as well, it was very informative and great to see everybody's perspective.

Some additional notes:

• Currently double click on an editor tab offers a "save as" option
  • However this feature is not very well known and not very discoverable
  • This probably doesn't fit the criteria here anyway, as the tab changes to the new file, so a "code.py" saved as "my_file.py" will then start saving into "my_file.py" as if it had closed the "code.py" tab
• The current version of Mu remembers the last mode used and opened tabs, so a CircuitPython user will usually have the code.py file from their device automatically opened when Mu starts up
  • If the file is not available when Mu starts, i.e. the CircuitPython device is not plugged in, then the code.py tab is no opened. There is no warning or indication of this, Mu simply opens the files from the previous session that it can still find
• For all other modes Mu has an autosave feature, where it periodically saves the opened files, but in CircuitPython mode this was deactivated, as the file save was naive and made the device restart the program every few seconds
  • Depending on what we decide here we could still make this work by only saving the file if the contents are different

From the current proposals:

Add a new "Run" button (whose visibility can be changed via the admin pane)

In this case I would vote for a run button that is always present, rather than a setting. To maintain Mu simple I would prefer to choose to change the UI rather than provide options to change it or customise it in a per-user bases.

All the other modes have a run/play/flash button, CircuitPython is the only mode currently that doesn't have a button that clearly indicates "I want to execute this code". This is the main reason a "Run" button looks attractive to me.

While changing the UI can affect existing literature (books, tutorials, workshops, educational material, etc), in this case the new button is an addition that does not change the behaviour of the rest of the buttons or Mu options. So instructions should still be valid, and while screenshots will be a bit different it should be easy to understand the difference and I think it should be fine for most users.

Other option:

• If a run button is not added, maybe (just maybe, I'm not totally convinced about this one) we could automatically open the code.py file when a device is found if it's not already opened.
  • Instead of automatically opening it we could instead open an info modal with a short intro and a "open code.py" and "ignore" button, although this could be annoying
  • The goal for this would be to make it a bit more obvious that editing code.py is the way to "run your code"
    • However, to be fair, CircuitPython users are likely to know this and might not need the reminder

[fmorton]

I have been rereading all of the comments both here and on the PR to clarify my own thinking.

One new path I went down was considering a general github integration for all modes, but that seems even more mirky than this issue.

@ntoll suggested in our video discussion just changing the behavior of the "Save" button to always copy the code if it is not already on the device. @ntoll had also suggested something like this back in June 2018, but making it an opt-in feature selected through "Mu Administration". This has the advantage of not causing the interface to change. I was starting to lean this way, but realized that it is common to "Save" work intermittently while making a set of changes, not intending the steps to actually be "Run" until all the changes are completed. So, a separate "Save" and "Run" button does make sense.

This lead me to think about one possible solution @carlosperate proposed of just adding the "Run" button all the time to align more with other modes, making it available all of the time. This is the simplest solution, which is frequently good and probably the best solution considering all the options.

A couple of downsides to this is the interface change affects existing literature, as @carlosperate reminded everyone. There is also a risk that teachers might find this confusing because they have already dealt with the only copy of the code living on the device in whatever way they have and will need to either do some reteaching or at least deal with some general confusion. This is why I liked adding the "Run" button optionally as an opt-in feature similar to the @ntoll suggesting of the opt-in behavior of the "Save" button. I will completely defer to the group on making the "Run" button optional since both approaches seem valid.

So, my conclusion at this point is to add the "Run" button full-time. If the "Run" button is selected, the file is saved to the local filesystem and a copy of it is made to CIRCUITPY/code.py. If the file is already on the CIRCUITPY device, it acts just like "Save".

I am craving some feedback from the teachers about this, though I would expect some resistance. Do we have any teachers we could ask about this that we know are actively using mu + circuitpython to see if we get any sort of reaction to the proposed change?