Replicate path to the project from local machine on remote machine.

[artem-zinnatullin]

At the moment Mainframer 2.x creates following path on remote machine:

Example:

local machine path : ~/projects/mycompany.com/project-x
remote machine path: ~/mainframer/project-x

As we scale Mainframer for OS-wide usage #185, chances of folder name clashing increase.

Example:

local machine path 1: ~/projects/mycompany.com/project-x
local machine path 2: ~/project-x

remote machine path 1: ~/mainframer/project-x
remote machine path 2: ~/mainframer/project-x

In the example above projects with different path on local machine end up in same path on remote machine.

This is unfortunate and unexpected by user.

I propose following simple solution: include part of local machine project path after $HOME into remote path.

Example:

local machine path 1: ~/projects/mycompany.com/project-x
local machine path 2: ~/project-x

remote machine path 1: ~/mainframer/mycompany.com/project-x
remote machine path 2: ~/mainframer/project-x

---

Important note: this change is incompatible with Mainframer 2.x.
However it'll just work in many cases, but users will have old unused folder on remote machine.

@ming13 wdyt?

[arturdryomov]

So yeah, it will not work with any directory out of the home one (BTW stop calling it folder like a Windows animal). I think the more scalable approach is to leave it as is and add a project-specific option (might complicate things though). Or just don’t do anything at all since it seems to be an edge-case, isn’t it?

[artem-zinnatullin]

Good point, sometimes project can be outside of $HOME dir, however I bet this is not really common on Unix.

To support both cases, we can actually replicate full path from local machine on remote machine:

local machine path : /var/www/projects/mycompany.com/project-x
remote machine path: ~/mainframer/var/www/projects/mycompany.com/project-x

WDYT?

---

We should definitely add a config option to set remote path in future, but there are few complications (specifically in terms of how things like ~ should be expanded) so I'd prefer to do it later.

[arturdryomov]

👍

[dmitry-novikov]

Taking into account proposed approach, maybe it's a good idea to resurge @AntonRutkevich idea to replace remote dirs in output with the local ones? #184

It should be simpler now because it can be done only via stripping out ~/mainframer from the output.

[artem-zinnatullin]

That will only work for projects that locally are stored under ~ :(

That's what I wanted too, but @ming13 raised concern:

So yeah, it will not work with any directory out of the home one

Absolute path should be good, do you see any problems with it other than deeper nesting in the directories?

[dmitry-novikov]

That will only work for projects that locally are stored under ~ :(

If you convert local folder to a full path then even ~/projects/my-project should work.

local machine path : ~/projects/my-project
remote machine path: ~/mainframer/home/user/projects/my-project

Or I miss something?

If I'm right, then to support #184 all you need to do is to replace all ~/mainframer/ with / in output.

[artem-zinnatullin]

Ah wait, sorry I misread your original comment, yes I think we can render remote paths as local ones in the output no matter where we put the files remotely

I thought you were proposing to not use absolute paths, my bad, it's time to go sleep I guess

[artem-zinnatullin]

@dmitry-novikov can you please file a separate issue for that with links to @AntonRutkevich 's PR and short description?

Otherwise I'll forget about it again :)

[dmitry-novikov]

#237