Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
itiligent opened this issue Sep 10, 2024 · 2 comments
Labels
bug Something isn't working enhancement New feature or request good first issue Good for newcomers legacy Using legacy winapps

Comments

@itiligent
Copy link
Contributor

itiligent commented Sep 10, 2024

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 oskardotglobal added the enhancement New feature or request label Sep 10, 2024
@oskardotglobal
Copy link
Member

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
Copy link
Contributor Author

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.

@oskardotglobal oskardotglobal added bug Something isn't working legacy Using legacy winapps good first issue Good for newcomers labels Dec 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request good first issue Good for newcomers legacy Using legacy winapps
Projects
None yet
Development

No branches or pull requests

2 participants