Split default spec into sections

[kuzeyron]

First attempt on splitting the default spec so the user will only be greeted with the minimal spec file if just running buildozer init.

Usage:
- buildozer init
- buildozer init android
- buildozer init android --no-comments
- buildozer init ios
- buildozer init ios --no-docs
- buildozer init osx

Each options includes the documentation and default text to the buildozer.spec file and also aware not to include duplicates just to make it easier for the user.

These steps involves making it easier in the future for the developers to change default values without messing up the documentations.

With this PR I have also updated the default values to match our daily usage with Buildozer.

[kuzeyron]

Android integration seems to be failing because Buildozer doesn't automatically accept the licenses.
iOS part is complaining about it cannot deploy the application.

[T-Dynamos]

setup.py doesn't add *.json files by default. Maybe change to

--- a/setup.py                                                                  
+++ b/setup.py                                                                  
@@ -68,7 +68,7 @@ setup(                                                        
     packages=[                                                                 
         'buildozer', 'buildozer.targets', 'buildozer.libs', 'buildozer.scripts'
     ],                                                                         
-    package_data={'buildozer': ['default.spec']},                              
+    package_data={'buildozer': ['default*.*']},                                
     include_package_data=True,                                                 
     install_requires=[                                                         
         'pexpect',                                                             

[T-Dynamos]

Android CI fails because of the leading space in the commented SDK-license line. Removing that space (as in this patch) fixes the sed match.

diff --git a/.github/workflows/android.yml b/.github/workflows/android.yml                                    
index 65c8f63..c1d9a9f 100644                                                                                 
--- a/.github/workflows/android.yml                                                                           
+++ b/.github/workflows/android.yml                                                                           
@@ -30,7 +30,7 @@ jobs:                                                                                       
     - run: buildozer init                                                                                    
     - name: SDK, NDK, and p4a download                                                                       
       run: |                                                                                                 
-        sed -i.bak "s/# android.accept_sdk_license = False/android.accept_sdk_license = True/" buildozer.spec
+        sed -i.bak "s/#android.accept_sdk_license = False/android.accept_sdk_license = True/" buildozer.spec 
         sed -i.bak "s/#p4a.branch = master/p4a.branch = develop/" buildozer.spec                             
         buildozer android p4a -- --help                                                                      
     # Install OS specific dependencies                                                                       

[kuzeyron]

Good catch @T-Dynamos ! Now it's just iOS that is failing..

[T-Dynamos]

It might be useful to add a --no-docs or --no-comments option, so the generated spec file can omit documentation comments. This would help keep the output minimal and cleaner for users who prefer a more compact file.

[kuzeyron]

Added that + possible cure for the deploy part for the ios part.

[kuzeyron]

PR is ready for review.

[T-Dynamos]

LGTM - Great work!

[akshayaurora]

Hiding the defaults would add to confusion just for the purpose of making it simpler for those who don't need the options.

I would much rather retain the default as is.

The purpose of default spec is to ::

• Offer a default specification which contains all features.
• User can edit the things they want ignoring other options they do not need to.

This PR goes against those basic tenets /principals of what a "Specification" is supposed to do/be.

I would suggest retaining the current behavior for the default spec which shows all options.
For a simpler minimal spec one could add something like ::

>> buildozer init minimal
>> buildozer init <- retains existing behavior.

[kuzeyron]

I can add more information to the default.spec file. I'm tired of seeing unrelated configs every time I make a new init file. Also these changes makes sure that all commands are following the concept which it haven't been before.

[AndreMiras]

Thanks for picking that up @kuzeyron 🙏 and thanks to both @T-Dynamos and @akshayaurora for reviewing.
I think @akshayaurora may have a good point in a way that we don't break the default behavior at least meanwhile still making it possible to address your use case of minimal spec file. The only thing is to change the option to make it explicit we want it minimal, but the default stays as it was.
What do you think?

[kuzeyron]

Thanks for picking that up @kuzeyron 🙏 and thanks to both @T-Dynamos and @akshayaurora for reviewing. I think @akshayaurora may have a good point in a way that we don't break the default behavior at least meanwhile still making it possible to address your use case of minimal spec file. The only thing is to change the option to make it explicit we want it minimal, but the default stays as it was. What do you think?

I chose to update them because I had to bump other versions as someone had only updated the default spec but never the default value in the code. Buildozer haven't been working properly and I have addressed some of that in this PR. If this PR gets the green light, the next PR will cover the rest so in the future the person who changes versions cannot mess things up.

Intention of the buildozer.spec is to read options that we can override and if the user leave options out, Buildozer defaults to whatever the code says in __init__.py. And that's the proper way of doing it. So in the end osx, ios and android is handled correctly with this PR.

[AndreMiras]

Thanks for the update.
To be honest, I don't have a super strong opinion on the default behavior specifically. The PR already brings a lot of value even without changing what buildozer init outputs by default.
That said, changing CLI behavior does create some friction (as we're seeing here). Since akshayaurora raised concerns about the new default, my suggestion would be: keep buildozer init behaving as it does today for now, and save the "minimal by default" change for a follow-up PR where you can make the case for it separately.
Easier to land the main improvements first, then revisit the default later in a dedicated one if it still makes sense.
What do you think?