refactor: Move code from main.go to other files #164
Conversation
jirihnidek
commented
Nov 5, 2024
•
jirihnidek
commented
- Card ID: CCT-950
- Initial step of refactoring main.go.
- Code moved from main.go to other files
- Introduced new files for connect and disconnect commands
- Added several other files for interactive mode, logging
- Some code was moved to existing files
- Unused code was removed.
There was a problem hiding this comment.
I have a concern with the change caused by this PR. While I see the benefit to reorganizing the files, this PR will create conflicts that need to be resolved in other PRs when they rebase onto these changes. This project is under fairly active development by a few different authors, and I would like to avoid putting unnecessary conflict resolution into those other PRs, if possible. Could we be more methodical about the refactor? Perhaps we could move the functionality of subcommands one commit at a time? Or first mark these "action" functions as deprecated, build new subcommand data structures that call back into these original "action" functions and then remove them?
I do something similar to this in xrhidgen. Each subcommand is declared as a global variable (for instance, associateCommand). Because that variable is a Command instance, it can be listed directly in the top level list of subcommands (as seen here in main.go).
Perhaps we can do something like that? There is no scenario I can think of that won't force some sort of conflict resolution upon the other outstanding PRs, but I'd like to make sure we do what we can to reduce the amount of conflict resolution we put upon the other PRs.
jirihnidek
force-pushed
the
jhnidek/refactor_main
branch
from
9a7f4e7
to
ee1a381
Compare
There is no open PR that could IMHO have conflict with this PR, because other opened PRs are related to build system & |
I see where you're coming from. It is a good time to reorganize things into files. And no matter what, we'll have to eventually convert these action functions into something else. I just want to make sure we're being conscious of what impact a reorganization like this will have on other committers. I think if we just separate the removal of unused functions into a separate commit, this will be fine to merge. |
* Card ID: CCT-950 * Initial step of refactoring main.go. * Code moved from main.go to other files * Introduced new files for connect and disconnect commands * Added several other files for interactive mode, logging * Some code was moved to existing files * Renamed register.go to rhsm.go, because it contains code not only for registration
* This function is not needed anymore. This function has not been used since #149 was merged
* This function has not been used since PR #149 was merged to main branch * No need to use go-ini module
* This function was used only in GuessAPIURL() and it was removed in previous commit: f7e8ffa
jirihnidek
force-pushed
the
jhnidek/refactor_main
branch
from
ee1a381
to
82e8795
Compare
