[Starlingx-discuss] [Build] unified build command suggestions

[Saul Wold]

On 09/05/2018 09:32 AM, Dean Troyer wrote:
> I've spent a few cycles thinking about CLI construction (syntax-wise)
> and have come to believe that not all command forms are created equal
> and that rigorous consistency is a big feature.
> 
> I think using something that looks like an option as the command can
> be confusing to users, it is better to use a form of object-action
> with options or positional arguments (the fewer the better).  If
> you've used OpenStackClient you will know exactly what I am talking
> about.
> 
I agree with this, similar to what git and some other tools do also, I 
like the examples you provided below.

Sau!

> Also, as an aside, I would really like to suggest not using 'stx' as
> the command for build-related things and saving that for user/cloud
> consumer things.
> 
> On Wed, Sep 5, 2018 at 8:31 AM, McKenna, Jason
> <Jason.McKenna at windriver.com> wrote:
>> I’ve been thinking about the proposal for the unified build command as
>> discussed in the last build team meeting.  “stx --build-iso” or “stx
>> --create-iso” was suggested as command for building all targets – source
>> rpms, binary rpms, and the final ISO.  We should probably change that
>> command name to “stx --build-all” or something similar.  This would meet the
>> immediate request of providing a single command to wrap around the existing
>> steps, and would allow us to grow the tool’s functionality without tying us
>> to the concept of “an ISO == a build”.  As a bonus, it allows us to improve
>> the granularity the build commands while maintaining a consistent command
>> naming convention.  A potential first cut of commands could be:
> 
> In the below examples I am assuming object - action ordering, which
> turned out to be easier to set up bash completion for than action -
> object ordering in OSC.  (Personally I prefer the latter)
> 
>> # Download items specified in lst files (replaces download_mirror.sh)
>> stx --mirror-download
> 
> stxb mirror download
> 
>> # Places downloaded items in the specified mirror path
>> stx --mirror-populate <mirror_path>
> 
> stxb mirror populate [-mirror <path>]
> 
>> # Do all mirror steps
>> stx --mirror-all <mirror_path>
> 
> stxb mirror create [-mirror <path>]
> (or init or update or whatever action name)
> 
>> # sets up a build environment with artifacts from the specified mirror path
>> (replaces generate-cgcs-centos-repo.sh and populate_downloads.sh)
>> stx --build-env <mirror_path>
> 
> stxb environment create [-mirror <path>]
> 
>> # builds specified package or all packages (replaces build-pkgs)
>> stx --build-pkgs [pkg_name]
> 
> stxb package build [<package-name> ...]
> 
>> # Produces an ISO from current build (replaces build-iso)
>> stx --build-iso
> 
> stxb iso build
> 
I think it would be better if was more like

stxb build iso

stxb build all

I know this is different than the mirror actions above, but the all does 
not ma
>> # Runs previous steps (I’m not sure if running --build-env during build-all
>> is a good idea, but perhaps we could skip the --build-env if no mirror_path
>> is specified)
>> stx --build-all [mirror_path]
> 
> stxb all build [-mirror <path>]
> 
I think it would be better if was more like
stxb build package
stxb build iso

stxb build all

I know this is different than the mirror actions above, but the "all" 
does not make sense to me in this usage.

Sau!

> 
> dt
>