Makefile .env copy confirmation implemented

[vehsamrak]

Command cp is mutable, so it would be better to confirm execution to leave control to the user.

[vehsamrak]

fyi: https://gist.github.com/Pierstoval/b2539c387c467c017bf2b0ace5a2e79b

[samizdam]

@vehsamrak thank you for suggestion.

I think, it's over much (code and logic) for this case.

I saw (and known) some user stories around this functionality:

1. As Newbie, I want run solution with minimal commands, for fast bootstrap my projects, that need virtual hosts.
2. As Maintainer, I want keep my projects with same (and simple as possible) dev flow, for simplest support and usage.
3. As Hacker, I want have workaround for manipulate local .env file.

For 1 US, run without prompts and supported options is better as more simple and fast. I want keep it simple.

For 2 US, I have more than 12 projects with very similar Makefiles, and suggested difference not give benefits for long term support it's all, or I need spend many time for reuse this feature, or copy-paste to other projects.

For 3 US, you can append to .env file what you need after install and before run. Or replace it as you want.

[vehsamrak]

I think copying files on behalf of user and without user notice is bad practice, and could be considered as disrespect.

The argument for projects with very similar Makefiles is the separated function (like in gist above).

[vehsamrak]

I stripped colors and result messages from confirmation logic to become as simple as possible

[samizdam]

I think, the simplest and user friendly way is move cp call to install section, when it is needed.
And use posix option -i without some wrapping.

So, we have 2 cases:

1. On clear install after clone cp -i work silently. If user put file before install, he should know what he want.
2. On repeat install - script suggest with native prompt replace or not it.

install, in common work flow, called once. And call cp every time not required.

PS: on run compose up services if .env was changed.

[vehsamrak]

Sounds decent. Main problem with this approach is that install section depends on environment variable, defined in .env - DEV_ROUTER_NETWORK. This could be mitigated by sourcing .env to shell after copying.

Take a look please

[vehsamrak]

$$VAR from shell, instead of $(VAR) from make

[samizdam]

I am get feedback, from mac user: -i with n return non zero and abort execution :(

[samizdam]

I think copying files on behalf of user and without user notice is bad practice, and could be considered as disrespect.

The argument for projects with very similar Makefiles is the separated function (like in gist above).

Unfortunately, make does not have package manager for simple code re-usage.

And same expected functionality, behavior and code in different projects is prior.