Migrate to mpbridge

[AmirHmZz]

I'm the maintainer of mpbridge project. It's a CLI tool to synchronise and manage files on a MicroPython running device. It depends on mpremote and uses it to communicate with boards. As long as mpremote is maintained by MicroPython maintainers officially, It's more reliable to depend on it.
I've been using your plugin for about 7 months until I found myself struggling repetitive flashing scripts slowly and re entering repl to debug my codes, so I created my own utility called mpbridge to facilitate my tasks.
I recommend you to take a look at repo and then think about migrating to mpbridge OR getting inspired by some of its features.

[Elizaveta239]

Thank you very much! We'll look into it!

[garynthompson]

On a similar thread, I have noticed that the plugin is using ampy which does not appear to be actively maintained. I am probably more in favour of the plugin switching to mpremote as this is the official micropython flashing tool and is likely to stay maintained with micropython. I appreciate that my suggestion on its own is not helpful as I don't have a PR to go with it. Maybe someday.

[elmot]

@AmirHmZz what is a benefit of your mpbridge over mpremote utility?

[AmirHmZz]

It's been 19 months since the first release of mpbridge and personally as a full time python and micropython developer I admit It has improved my productivity especially in large projects (+150 Files) which syncs the whole project in less than 7 secs including hard resetting the board.
But let's dive into a brief comparison between mpbridge and mpremote:

• mpbridge is developed on top of mpremote and aims to make development faster on micropython boards.
• Comparing to current behaviour of plugin, mpbridge avoids copying unchanged files on target device which saves a significant amount of time while syncing directories.
• mpbridge sync uses file's hashes to find changed files and avoids unnecessary file reads and copies which take a lot of time in syncing big projects.
• since mpbridge 1.5.1 an hash table is saved on target device to store latest file hashes in order to avoid redundant hashing on target device. Using hash table also prevents the synchronization time from increasing due to the increase in the number of files.
• mpbridge's dev mode can perform a hard reset after each sync and also starts REPL right after reboot which makes cyclic procedure ( Develop > Run > Develop) all and all with just one CLI command.

[elmot]

Thanks for the answer.

in large projects (+150 Files)
That's impressive! I have never thought this kind of projects exists.

Ok, I see. The main advantage of mpbridge is that the library keeps track of changed files. Other features could be easily implemented without it.

The idea of hashes looks nice. To be honest, keedping track of hashes on the device seems a bit fragile to me: files may be modified somehow without mpbridge, and then thigs go a little bit out of control.

Why I am asking you - I am deciding where to migrate from adafruit-ampy. mpremote and related stuff is is one option, but it has a great disadvantage - it does not support webrepl. So I'd probably prefer in-house kotlin communication library based on mpremote's ideas.

[AmirHmZz]

The idea of hashes looks nice. To be honest, keeping track of hashes on the device seems a bit fragile to me: files may be modified somehow without mpbridge, and then things go a little bit out of control.

I didn't get what you mean but I can guess you've mentioned one of these cases:

1. What happens If some micropython code changes some files on the target device?
On the next sync it will be rolled back again to the host's version. Even if it's been created by micropython on target device and the file does not exist on host, mpbridge deletes it. If this behaviour is unwanted, developers can use mpbridge.ignore file to prevent mpbridge syncing that specific file. In our project I usually ignore config files.

2. What happens If I use some other stuff to change files on target device?
hashing is done on target device (MCU calculates hash of files instead of sending the whole file to check if It's changed) and hash table also is stored on target device. This will guarantees mpbridge sync won't miss any files in any case. (tell me If you think there's a case!)

I am deciding where to migrate from adafruit-ampy. mpremote and related stuff is is one option, but it has a great disadvantage - it does not support webrepl. So I'd probably prefer in-house kotlin communication library based on mpremote's ideas.

Writing the whole communication stuff seems risky to me. Micropython is an active project and changes a lot over time. In that case you should always update communication stuff with the main repo and If these changes are missed some issues start to appear like #283, #274 and #271.

By the way, in our company we will never deliver raw .py or .mpy files to our customers chips over web REPL. The whole firmware will be encrypted including freezed micropython files and then the whole firmware will be updated Over-The-Air.

[elmot]

Well, I just looked into mpremote repo, almost nothing is changed on communication level during a long period.
The internals of the mpremote is not a rocket science either.

[AmirHmZz]

The internals of the mpremote is not a rocket science either.

Fixing #271 did not need rocket science either but it took 7 months to gets fixed! It's about how this plugin is being maintained 1-2 years later.

I recommend you to take a look at repo and then think about migrating to mpbridge OR getting inspired by some of its features.
As I mentioned earlier,

BTW, the decision is at your discretion! Inspiring by mpbridge would be a nice option too!