Feature Request: allow onyo mv <asset> <non-existing dir> to create parent directories

[TobiasKadelka]

In the past, we decided that onyo mv mirrors the unix mv in so far that it errors when asked to move something to a non-existing destination. Now we begin using onyo in the real world for a real inventory, and I changed my mind about this command.

IMO onyo mv <asset> <non-existing-dir> should create all non-existing parent directories.
When I create a new asset and directly asign it to a new user (which does not have a directory in onyo yet) with onyo new -d <non-existent>, then onyo prints the diff, which mentions the creation of both, the new directory and the new asset, and I can "Accept changes".

But if I have an existing asset, and I want to move it to a new user (which does not have a directory in onyo yet) with onyo mv <asset> <non-existent>, it errors and informs me that the move is illegal because the destination does not exist.

The arguments we had in the past for this that I remember were:

1. "guarding against typos" -> But we print already a diff and ask the user explicitely to accept changes with onyo mv anyways, it guards IMO against nothing.
2. "being closer to the unix mv" -> If I think about onyo commands as running python code that mirrors unix commands from the CLI, then this argument would make sense. But when I use onyo, I do not think about it that way; I think about it as inventorying. I have a device in front of me (or got the information from a employee), and I know to whom I want to asign it. In that moment I do not care about if the asset is "new" or simply "moved", and I do not think about if the user is "already tracked by the system" or if I am the first one to give them hardware.

In conclusion: this is why I think onyo mv should follow onyo new and simply create all new directories I specify as destination, and tell me it will do so, and then I as the user decide if that is what I want to do.

[nhjjr]

Good points, but it made me wonder why onyo new allows for the creation of non-existing dirs. The unix equivalents touch dir/file and cat > dir/file do not allow for that. Similarly, onyo mkdir creates (parent) dirs out-of-the-box, whereas the unix equivalent mkdir does not (unless invoked with the -p argument).

There are two important things to consider:

1. Consistency. All functionality must be consistent. If we want to mimic functionality of unix commands (and document it like that), then we should do so for all onyo functions.
2. Usability. Is the consistency we keep with unix commands more beneficial than the 'extra' functionality that is now suggested?

As for point 2, I think we can argue in both ways. I think there is use in giving all of these functions by default the ability to create (parent) dirs. However, we cannot "half-ass" this. If we give one this ability, then we should give it to the other.

On the other hand, if we deem consistency with unix functionality to be more important/beneficial, we should remove the creation of (parent) dirs from onyo new and add a -p to onyo mkdir when it is to be used to create parent dirs.

There is merrit to sticking to unix functionality. We assign meaning to directories--in our case this is location of the asset--so keeping the creation of a directory as a separate record has value. Otherwise, the creation of a location or user will sometimes be an onyo mkdir record, sometimes an onyo new record, and sometimes an onyo mv record. One could of course do onyo mkdir ... && onyo mv ... to still solve things in one line.

Does this merrit outweigh the usability Tobi suggests? I do not know.

[aqw]

Ironically, I mostly have arguments in support of this change, though my opinion is largely against this. Perhaps that is simply because I have not used Onyo in workflows that would expose me to the usefulness of this change. More example use cases would help. I do find the idea to be unintuitive, and removes what I find to be useful feedback (error when the target parent dir does not exist).

The unintuitive concern comes down to that it will behave differently than the traditional unix mv command. To address that, if this feature is accepted, I propose renaming onyo mv to onyo move.

My primary concern is typos/errors. I imagine the file system as a scaffolding. We build it intentionally, and when we need another space/person, we explicitly add it.

Diffs are not a magic catch all. Users largely will skim the output, and I suspect that most of us, when making a typo would not catch in the diff that the target dir is new. This can be improved upon with #656 (and possibly also #657) to help highlight significant changes.

As for consistency across commands, we can simply remove directory creation from onyo new to make it consistent. But I don't find it all that inconsistent to have new create. What I chew on is the idea that onyo set be allowed to set the directory pseudo-key. If we end up adding that, I do believe that it should create any needed parent directories. But somehow, that just /feels/ different than onyo mv.

I think it's because set isn't operating on the filesystem. It's operating on data/metadata. But filesystem operations, I imagine to work like the filesystem traditionally does.

Those are my thoughts. I'm not sure which direction they are headed. I'll continue to meditate on this. Additional input most welcome.

[TobiasKadelka]

Diffs are not a magic catch all. Users largely will skim the output

Here I might use onyo different than others, but I do spend a lot of time reading the diff and checking that everything is correct. And I would expect Jan and Ralf do the same (even though I have no proof for this part).

we can simply remove directory creation from onyo new to make it consistent

You are not the first person to state something like this. I am strongly against this change. The idea to make onyo even just a little less comfortable to use just for the sake of an idea of consistency makes me shiver.
I do however like the idea to allow onyo set to be more power for the same reasons as listed above for onyo mv ;)

I propose renaming onyo mv to onyo move

If that is something that would help others, I am definitely happy with this change, even without the feature requested in this issue :)

More example use cases would help

Frankly, I do not have that many more example use cases, it always boils down to the same scenario:

• I gave a user a new laptop or I brought an adapter to a room in we did not track yet
• I look for the device which I moved in the real world in onyo, and want to add this real world move to the inventory
• I am briefly annoyed that I get the error (or can't find the destination directory), and so I have to first create the new user seperately, and then once again I do the move command for the device in the inventory

I do not even have a "strong need" for this change to happen, for me it just would be a little convenience. But currently this is a little rough edge in onyo for me; not a big problem, just a small annoyance each time, but regularly. We now have most rooms tracked, but new users will join all the time and then we will give them their first piece of equipment, and this inconvenience happens every time. I know Jan made the same experience. For me it boils literally down to "the two people who moved the most hardware in the real world by now made the same experience and did not find it positively great".

-> If everybody else is against it, we will learn to live with it, but I personally like the direction you bring up of asking if there are other changes that would make this this more intuitive. Renaming the command to onyo move, adding bold highlighting and the operations records to the diff, and possibly allowing onyo set additional abilities are probably all good ideas on their own and might help this feature to feel more natural, too.