[Starlingx-discuss] [Build] unified build command suggestions
Hi Cesar and build team, 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: # Download items specified in lst files (replaces download_mirror.sh) stx --mirror-download # Places downloaded items in the specified mirror path stx --mirror-populate <mirror_path> # Do all mirror steps stx --mirror-all <mirror_path> # 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> # builds specified package or all packages (replaces build-pkgs) stx --build-pkgs [pkg_name] # Produces an ISO from current build (replaces build-iso) stx --build-iso # 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] Future commands like --build-patch or --sign-pkgs or --project-integrate or wherever this grows, could be added as more advanced use cases are fleshed out. Jason
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. 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@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
# 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>] dt -- Dean Troyer dtroyer@gmail.com
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@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
On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw@linux.intel.com> wrote:
I agree with this, similar to what git and some other tools do also, I like the examples you provided below.
Sooooo..... git should mostly not be used as an example UI for most purposes, it is a bit of a mess :) git remote add ... (ok, but...) git branch -m ... (not branch move? branch is sometimes an object and sometimes a verb depending on the options!!)
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 make sense to me in this usage.
This is the what-comes-first question, the object or the action? VMS is still leaking from my brain in that I also prefer the action (verb) to be first. OSC reversed itself 5 years ago because of the bash-completion issue, we use cliff to implement the command parser (built on top of argparse) and doing verb-first and bash completion turned out to be a mess. That is an implementation driving design, which is not always great, but was acceptable to the team at the time. Which ever order is settled on, PLEASE make all commands the same. The UX studies we did with OSC always showed this consistency to be very important to both new and experienced users. dt -- Dean Troyer dtroyer@gmail.com
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: September 5, 2018 1:54 PM To: Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw@linux.intel.com> wrote:
I agree with this, similar to what git and some other tools do also, I like the examples you provided below.
Sooooo..... git should mostly not be used as an example UI for most purposes, it is a bit of a mess :)
git remote add ... (ok, but...) git branch -m ... (not branch move? branch is sometimes an object and sometimes a verb depending on the options!!)
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 make sense to me in this usage.
This is the what-comes-first question, the object or the action? VMS is still leaking from my brain in that I also prefer the action (verb) to be first. OSC reversed itself 5 years ago because of the bash-completion issue, we use cliff to implement the command parser (built on top of argparse) and doing verb- first and bash completion turned out to be a mess. That is an implementation driving design, which is not always great, but was acceptable to the team at the time.
Which ever order is settled on, PLEASE make all commands the same. The UX studies we did with OSC always showed this consistency to be very important to both new and experienced users.
+1 on consistency :) I think we need discussion around what we're really trying to accomplish. Going back to Cesar's initial proposal, the problem he wanted solved was that his team felt that there were too many commands required to produce an ISO after you've downloaded the mirrors (generate-cgcs-centos-repo.sh, build-pkgs, build-iso) and wanted to wrap those in a single command. Please correct me if I've misstated the problem, Cesar. Furthermore, I think you were looking for a command which did the steps that a developer would execute and not do the steps that a developer would not (downloading the mirror, is intended to be done at a per-site level, not a per-developer level, and would not necessarily be included in the single-command). Finally, the command was intended to be expandable and adaptable in the future (again, please correct me if I've misstated anything). Other than the "meet all conceivable future needs" requirement, I don't see much that couldn't be done with something like a Makefile: make mirror make environment make build make iso especially if you have the "iso" target depend on the "build" target which depends on the "environment" target, etc, then the whole process boils down to one "make iso" command for a developer (2 commands if they have to download the mirror themselves). Note that I'm not proposing "make" as a solution, I understand the concern that make wouldn't meet our needs in the future, and make can be less than pretty. I'm more engaging in the thought exercise of "what problem are we really trying to solve and has anyone solved it in the past" If we're wrapping or re-writing the build commands to make it simpler/easier for a developer, we should define proper use cases and make sure we're solving the right problems. To go off on a tangent, I find the illegible output of the build commands to be much more a stumbling block than the fact that I have to execute 3 commands rather than 1 to produce a build.
dt
--
Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi team, Related to the tool name, a good point was mentioned, StarlingX is the core project, “stx” should be reserved for the core things. The building tool will be called “stx-build-tool” or “stx-bt” and it is good to keep consistency with the current stuff. And about the different options/subcommands proposed by Jason, they can exist, the idea is to cover both sides, develop and user sides. It is possible to have users that maybe would not like to involve in the development process and they just want to get ISO image, this is a valid point and our build tool should allow that way, the next proposed commands should be enough for a “Quick user guide”. $ stx-build-tool mirror create $ stx-build-tool iso build By the other hand the developers need more granularity about the processes, then the subcommands proposed by Jason are welcome. The implementation of this script will be modular, then it will be easy to implement relevant and needed subcommands in a future just calling the required functions. An related to the comment about Makefile rules, I think it could be better to use shell commands directly instead to wrap them in a Makefile, due to it is easier to customized values on command line. Using Makefiles it is possible to do it too, but I think it is a little less friendly. Best Regards. Mario. ________________________________________ From: McKenna, Jason [Jason.McKenna@windriver.com] Sent: Wednesday, September 05, 2018 11:02 AM To: Dean Troyer; Saul Wold Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: September 5, 2018 1:54 PM To: Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw@linux.intel.com> wrote:
I agree with this, similar to what git and some other tools do also, I like the examples you provided below.
Sooooo..... git should mostly not be used as an example UI for most purposes, it is a bit of a mess :)
git remote add ... (ok, but...) git branch -m ... (not branch move? branch is sometimes an object and sometimes a verb depending on the options!!)
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 make sense to me in this usage.
This is the what-comes-first question, the object or the action? VMS is still leaking from my brain in that I also prefer the action (verb) to be first. OSC reversed itself 5 years ago because of the bash-completion issue, we use cliff to implement the command parser (built on top of argparse) and doing verb- first and bash completion turned out to be a mess. That is an implementation driving design, which is not always great, but was acceptable to the team at the time.
Which ever order is settled on, PLEASE make all commands the same. The UX studies we did with OSC always showed this consistency to be very important to both new and experienced users.
+1 on consistency :) I think we need discussion around what we're really trying to accomplish. Going back to Cesar's initial proposal, the problem he wanted solved was that his team felt that there were too many commands required to produce an ISO after you've downloaded the mirrors (generate-cgcs-centos-repo.sh, build-pkgs, build-iso) and wanted to wrap those in a single command. Please correct me if I've misstated the problem, Cesar. Furthermore, I think you were looking for a command which did the steps that a developer would execute and not do the steps that a developer would not (downloading the mirror, is intended to be done at a per-site level, not a per-developer level, and would not necessarily be included in the single-command). Finally, the command was intended to be expandable and adaptable in the future (again, please correct me if I've misstated anything). Other than the "meet all conceivable future needs" requirement, I don't see much that couldn't be done with something like a Makefile: make mirror make environment make build make iso especially if you have the "iso" target depend on the "build" target which depends on the "environment" target, etc, then the whole process boils down to one "make iso" command for a developer (2 commands if they have to download the mirror themselves). Note that I'm not proposing "make" as a solution, I understand the concern that make wouldn't meet our needs in the future, and make can be less than pretty. I'm more engaging in the thought exercise of "what problem are we really trying to solve and has anyone solved it in the past" If we're wrapping or re-writing the build commands to make it simpler/easier for a developer, we should define proper use cases and make sure we're solving the right problems. To go off on a tangent, I find the illegible output of the build commands to be much more a stumbling block than the fact that I have to execute 3 commands rather than 1 to produce a build.
dt
--
Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
My $0.02, for what it's worth. The name stx-build-tool is too long. +1 to stxb from a previous note in this thread. brucej -----Original Message----- From: Arevalo, Mario Alfredo C [mailto:mario.alfredo.c.arevalo@intel.com] Sent: Wednesday, September 5, 2018 3:13 PM To: McKenna, Jason <Jason.McKenna@windriver.com>; Dean Troyer <dtroyer@gmail.com>; Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions Hi team, Related to the tool name, a good point was mentioned, StarlingX is the core project, “stx” should be reserved for the core things. The building tool will be called “stx-build-tool” or “stx-bt” and it is good to keep consistency with the current stuff. And about the different options/subcommands proposed by Jason, they can exist, the idea is to cover both sides, develop and user sides. It is possible to have users that maybe would not like to involve in the development process and they just want to get ISO image, this is a valid point and our build tool should allow that way, the next proposed commands should be enough for a “Quick user guide”. $ stx-build-tool mirror create $ stx-build-tool iso build By the other hand the developers need more granularity about the processes, then the subcommands proposed by Jason are welcome. The implementation of this script will be modular, then it will be easy to implement relevant and needed subcommands in a future just calling the required functions. An related to the comment about Makefile rules, I think it could be better to use shell commands directly instead to wrap them in a Makefile, due to it is easier to customized values on command line. Using Makefiles it is possible to do it too, but I think it is a little less friendly. Best Regards. Mario. ________________________________________ From: McKenna, Jason [Jason.McKenna@windriver.com] Sent: Wednesday, September 05, 2018 11:02 AM To: Dean Troyer; Saul Wold Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: September 5, 2018 1:54 PM To: Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw@linux.intel.com> wrote:
I agree with this, similar to what git and some other tools do also, I like the examples you provided below.
Sooooo..... git should mostly not be used as an example UI for most purposes, it is a bit of a mess :)
git remote add ... (ok, but...) git branch -m ... (not branch move? branch is sometimes an object and sometimes a verb depending on the options!!)
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 make sense to me in this usage.
This is the what-comes-first question, the object or the action? VMS is still leaking from my brain in that I also prefer the action (verb) to be first. OSC reversed itself 5 years ago because of the bash-completion issue, we use cliff to implement the command parser (built on top of argparse) and doing verb- first and bash completion turned out to be a mess. That is an implementation driving design, which is not always great, but was acceptable to the team at the time.
Which ever order is settled on, PLEASE make all commands the same. The UX studies we did with OSC always showed this consistency to be very important to both new and experienced users.
+1 on consistency :) I think we need discussion around what we're really trying to accomplish. Going back to Cesar's initial proposal, the problem he wanted solved was that his team felt that there were too many commands required to produce an ISO after you've downloaded the mirrors (generate-cgcs-centos-repo.sh, build-pkgs, build-iso) and wanted to wrap those in a single command. Please correct me if I've misstated the problem, Cesar. Furthermore, I think you were looking for a command which did the steps that a developer would execute and not do the steps that a developer would not (downloading the mirror, is intended to be done at a per-site level, not a per-developer level, and would not necessarily be included in the single-command). Finally, the command was intended to be expandable and adaptable in the future (again, please correct me if I've misstated anything). Other than the "meet all conceivable future needs" requirement, I don't see much that couldn't be done with something like a Makefile: make mirror make environment make build make iso especially if you have the "iso" target depend on the "build" target which depends on the "environment" target, etc, then the whole process boils down to one "make iso" command for a developer (2 commands if they have to download the mirror themselves). Note that I'm not proposing "make" as a solution, I understand the concern that make wouldn't meet our needs in the future, and make can be less than pretty. I'm more engaging in the thought exercise of "what problem are we really trying to solve and has anyone solved it in the past" If we're wrapping or re-writing the build commands to make it simpler/easier for a developer, we should define proper use cases and make sure we're solving the right problems. To go off on a tangent, I find the illegible output of the build commands to be much more a stumbling block than the fact that I have to execute 3 commands rather than 1 to produce a build.
dt
--
Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Thank god for autocomplete *clicks tab* :P Regards Cesar Lara -----Original Message----- From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Wednesday, September 5, 2018 5:30 PM To: Arevalo, Mario Alfredo C <mario.alfredo.c.arevalo@intel.com>; McKenna, Jason <Jason.McKenna@windriver.com>; Dean Troyer <dtroyer@gmail.com>; Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions My $0.02, for what it's worth. The name stx-build-tool is too long. +1 to stxb from a previous note in this thread. brucej -----Original Message----- From: Arevalo, Mario Alfredo C [mailto:mario.alfredo.c.arevalo@intel.com] Sent: Wednesday, September 5, 2018 3:13 PM To: McKenna, Jason <Jason.McKenna@windriver.com>; Dean Troyer <dtroyer@gmail.com>; Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions Hi team, Related to the tool name, a good point was mentioned, StarlingX is the core project, “stx” should be reserved for the core things. The building tool will be called “stx-build-tool” or “stx-bt” and it is good to keep consistency with the current stuff. And about the different options/subcommands proposed by Jason, they can exist, the idea is to cover both sides, develop and user sides. It is possible to have users that maybe would not like to involve in the development process and they just want to get ISO image, this is a valid point and our build tool should allow that way, the next proposed commands should be enough for a “Quick user guide”. $ stx-build-tool mirror create $ stx-build-tool iso build By the other hand the developers need more granularity about the processes, then the subcommands proposed by Jason are welcome. The implementation of this script will be modular, then it will be easy to implement relevant and needed subcommands in a future just calling the required functions. An related to the comment about Makefile rules, I think it could be better to use shell commands directly instead to wrap them in a Makefile, due to it is easier to customized values on command line. Using Makefiles it is possible to do it too, but I think it is a little less friendly. Best Regards. Mario. ________________________________________ From: McKenna, Jason [Jason.McKenna@windriver.com] Sent: Wednesday, September 05, 2018 11:02 AM To: Dean Troyer; Saul Wold Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: September 5, 2018 1:54 PM To: Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw@linux.intel.com> wrote:
I agree with this, similar to what git and some other tools do also, I like the examples you provided below.
Sooooo..... git should mostly not be used as an example UI for most purposes, it is a bit of a mess :)
git remote add ... (ok, but...) git branch -m ... (not branch move? branch is sometimes an object and sometimes a verb depending on the options!!)
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 make sense to me in this usage.
This is the what-comes-first question, the object or the action? VMS is still leaking from my brain in that I also prefer the action (verb) to be first. OSC reversed itself 5 years ago because of the bash-completion issue, we use cliff to implement the command parser (built on top of argparse) and doing verb- first and bash completion turned out to be a mess. That is an implementation driving design, which is not always great, but was acceptable to the team at the time.
Which ever order is settled on, PLEASE make all commands the same. The UX studies we did with OSC always showed this consistency to be very important to both new and experienced users.
+1 on consistency :) I think we need discussion around what we're really trying to accomplish. Going back to Cesar's initial proposal, the problem he wanted solved was that his team felt that there were too many commands required to produce an ISO after you've downloaded the mirrors (generate-cgcs-centos-repo.sh, build-pkgs, build-iso) and wanted to wrap those in a single command. Please correct me if I've misstated the problem, Cesar. Furthermore, I think you were looking for a command which did the steps that a developer would execute and not do the steps that a developer would not (downloading the mirror, is intended to be done at a per-site level, not a per-developer level, and would not necessarily be included in the single-command). Finally, the command was intended to be expandable and adaptable in the future (again, please correct me if I've misstated anything). Other than the "meet all conceivable future needs" requirement, I don't see much that couldn't be done with something like a Makefile: make mirror make environment make build make iso especially if you have the "iso" target depend on the "build" target which depends on the "environment" target, etc, then the whole process boils down to one "make iso" command for a developer (2 commands if they have to download the mirror themselves). Note that I'm not proposing "make" as a solution, I understand the concern that make wouldn't meet our needs in the future, and make can be less than pretty. I'm more engaging in the thought exercise of "what problem are we really trying to solve and has anyone solved it in the past" If we're wrapping or re-writing the build commands to make it simpler/easier for a developer, we should define proper use cases and make sure we're solving the right problems. To go off on a tangent, I find the illegible output of the build commands to be much more a stumbling block than the fact that I have to execute 3 commands rather than 1 to produce a build.
dt
--
Dean Troyer dtroyer@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
+1 on consistency :)
I think we need discussion around what we're really trying to accomplish. Going back to Cesar's initial proposal, the problem he wanted solved was that his team felt that there were too many commands required to produce an ISO after you've downloaded the mirrors (generate-cgcs-centos-repo.sh, build-pkgs, build-iso) and wanted to wrap those in a single command. Please correct me if I've misstated the problem, Cesar. Furthermore, I think you were looking for a command which did the steps that a developer would execute and not do the steps that a developer would not (downloading the mirror, is intended to be done at a per-site level, not a per-developer level, and would not necessarily be included in the single-command).
I think the biggest motivation behind this effort is to simplify the build procedure for newcomers. It is true that in well established infrastructure there will be commands that won't be part of the common workflow for developers. However, since we started to build StarlingX we faced problems to understand and to repeat the procedure. From some emails in the mailing list we can see that new people trying to build have problems of different kinds. It would be good to have something that can tell "You can't start a build because you don't have a mirror downloaded" or "You have packages in the .lst files that are not in your mirror, try to update your mirror". I think that in opensource, adoption is one of the key parts. We need to improve the procedure for new people so they can continue using our project, otherwise they will jump to another, more easy think to build. -Erich
Hi, I think that Saul uses git as a reference in terms of how the git command redirects the input to the subcommands. If you run git foo, internally will try to run git-foo, so git-foo could be a bash script and it will work. We created a etherpad to capture features and use cases. You can see it here: https://etherpad.openstack.org/p/stx-build-tool-features The "Implement command line utility that works as a gateway for subcommands" feature covers this proposal. -Erich On Wed, 2018-09-05 at 12:53 -0500, Dean Troyer wrote:
On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw@linux.intel.com> wrote:
I agree with this, similar to what git and some other tools do also, I like the examples you provided below.
Sooooo..... git should mostly not be used as an example UI for most purposes, it is a bit of a mess :)
git remote add ... (ok, but...) git branch -m ... (not branch move? branch is sometimes an object and sometimes a verb depending on the options!!)
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 make sense to me in this usage.
This is the what-comes-first question, the object or the action? VMS is still leaking from my brain in that I also prefer the action (verb) to be first. OSC reversed itself 5 years ago because of the bash-completion issue, we use cliff to implement the command parser (built on top of argparse) and doing verb-first and bash completion turned out to be a mess. That is an implementation driving design, which is not always great, but was acceptable to the team at the time.
Which ever order is settled on, PLEASE make all commands the same. The UX studies we did with OSC always showed this consistency to be very important to both new and experienced users.
dt
This is a great suggestion, we'll see how to integrate this to the build command Regards Cesar Lara From: McKenna, Jason [mailto:Jason.McKenna@windriver.com] Sent: Wednesday, September 5, 2018 8:31 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] [Build] unified build command suggestions Hi Cesar and build team, 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: # Download items specified in lst files (replaces download_mirror.sh) stx --mirror-download # Places downloaded items in the specified mirror path stx --mirror-populate <mirror_path> # Do all mirror steps stx --mirror-all <mirror_path> # 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> # builds specified package or all packages (replaces build-pkgs) stx --build-pkgs [pkg_name] # Produces an ISO from current build (replaces build-iso) stx --build-iso # 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] Future commands like --build-patch or --sign-pkgs or --project-integrate or wherever this grows, could be added as more advanced use cases are fleshed out. Jason
participants (7)
-
Arevalo, Mario Alfredo C
-
Cordoba Malibran, Erich
-
Dean Troyer
-
Jones, Bruce E
-
Lara, Cesar
-
McKenna, Jason
-
Saul Wold