Skip to content

mpremote romfs deploy: Directory handling is arguably inconsistent with cp -r #17192

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.

Sign up for GitHub

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

Jump to bottom
Open
peterhinch opened this issue Apr 25, 2025 · 4 comments
Open

mpremote romfs deploy: Directory handling is arguably inconsistent with cp -r #17192

peterhinch opened this issue Apr 25, 2025 · 4 comments
Labels
enhancement Feature requests, new feature implementations tools Relates to tools/ directory in source, or other tooling

Comments

@peterhinch
Copy link
Contributor

Port, board and/or hardware

Board independent. Tested on RP2040

MicroPython version

MicroPython v1.25.0-dirty on 2025-04-19; Raspberry Pi Pico with RP2040

Built with romfs

Reproduction

Issue

$ mpremote deploy foo

where foo is a directory on the PC containing subdirectories

Expected behaviour

The command

$ mpremote cp -r foo :

copies the directory foo with contents and subdirectories to the host. This is consistent with

$ cp -r foo bar

Observed behaviour

By contrast

$ mpremote deploy foo

copies the contents of foo as per

$ cp -r foo/* bar

A typical project might consist of a Python package foo where the executable foo is contained in a directory holding documentation and other resources. The requirement is to copy foo and its contents. Currently this requires a workround involving a temporary directory and a symlink.

Additional Information

Options are either to change this behaviour or provide means of deploying either the directory + contents or contents alone.

Code of Conduct

Yes, I agree
@peterhinch peterhinch added bug tools Relates to tools/ directory in source, or other tooling labels Apr 25, 2025
@robert-hh
Copy link
Contributor

robert-hh commented Apr 26, 2025 •
edited
Loading

In contrast to the application you sketched here, people might NOT want to create a directory in ROMFS but just copy a few files. That would not possible with your suggested change, unless there would be an option whether the target directory is included or not. Or romfs deploy is changed to accept multiple arguments, which may be files or directories.
And no, I would not consider the current behavior a bug.

@peterhinch
Copy link
Contributor Author

unless there would be an option whether the target directory is included or not.

That would be ideal: both have common use cases.

I would not consider the current behavior a bug.

Well, me neither; but there isn't a tag for "inconsistency" :)

@robert-hh
Copy link
Contributor

You can clear the "bug" label and select "enhancement ".

@peterhinch peterhinch added enhancement Feature requests, new feature implementations and removed bug labels Apr 27, 2025
@smurfix
Copy link
Contributor

smurfix commented May 1, 2025

unless there would be an option whether the target directory is included or not

What for? Why not teach mpremote deploy foo to create a directory, while mpremote deploy foo/. simply deploys the files therein.

This is how rsyncworks, among other tools. mpremote should work the same way. Principle of least surprise and all that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Feature requests, new feature implementations tools Relates to tools/ directory in source, or other tooling
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@smurfix @peterhinch @robert-hh