winapps icon indicating copy to clipboard operation
winapps copied to clipboard

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

Open itiligent opened this issue 1 year ago • 3 comments

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. )

itiligent avatar Sep 10 '24 12:09 itiligent

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.

oskardotglobal avatar Sep 10 '24 15:09 oskardotglobal

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.

itiligent avatar Sep 10 '24 21:09 itiligent

I just wanted to add that, to new users (e.g. me), it is really confusing right now. I installed WinApps (no real issues there), but when I tried to add an application, I just couldn't figure out how to do it. I spent over an hour just trying to get WinApps to detect my application in the docker container; I tried %HOME/.local/share/winapps/apps (which didn't work as it's just wrong and, as i now know, only for detected applications; however the readme just said "apps" without telling me which), I tried locally cloning WinApps, putting my files in that's "apps" folder, using it's setup.sh, still didn't work. I only just found this issue here, which is the first place I ever noticed that there is a locally cloned repo already and I needed to put my stuff in ITS "apps" folder.

I mean now that I understood it's fine, and it would be fine if I was just told which apps folder I need to put my stuff in a the beginning, but the way it is now, it's just confusing (at least it was for me)

tm-frs avatar Feb 26 '25 23:02 tm-frs