search

winapps-org / winapps

The winapps main project, forked from https://github.com/Fmstrat/winapps/
Other
1.15k stars 55 forks source link

new setup.sh behaviour breaks installing/reinstalling from a local custom fork #249

Open itiligent opened 1 month ago

itiligent commented 1 month ago

The new behaviour of setup.sh is super unfriendly.

Running setup just re-clones the main repo to ~/.local/winapps-src and intalls from there - regardless of the repo being cloned locally already.

Not only is this doubling up on cloning, but BIG issue here is when you are wanting to install winapps from a custom local fork for testing . The current behaviour effectively ignores all local code, which forces all custom changes to be manually re-added each and every time setup is run.

I really think that setup should try to install from any local repo source first and certainly not ignore or overwrite customisations made to any local code. (This nearly caught me out testing a new PR, as I was thinking I was testing my own new code and all the while I wasn't testing anything new. )

oskardotglobal commented 1 month ago

Not only is this doubling up on cloning

Well, the idea is that the user does not clone the repository themselves anymore, they just curl-bash the setup scrip.t

BIG issue here is when you are wanting to install winapps from a custom local fork for testing

You can technically set the USER_SOURCE_PATH and/or USER_SOURCE_PATH to your local clone's directory. However, I agree that this is something that can be optimized. We could for example check if bin/winapps is present in the same directory as the setup.sh and then skip cloning.

itiligent commented 1 month ago

Yes indeed. I definitely see the merits of avoiding the need for users not to clone, so that makes perfect sense. However I would think it is also essential to be able to support more advanced types who will modify (and contribute back) in accomodating their own needs. A check to see if the source is already cloned would be great.

I think this is an important consideration because if undocumented and fiddly extra manual steps are required to reliably deploy changes (steps that run contrary to the way open source is typically handled) , this will catch people out, cause pain and waste time. This was my exact eperience in making a simple 5 min pull request that took half a day to troublshoot and test.