Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

Genericize Build Functionality #342

Open
michaeltlombardi opened this issue Feb 11, 2022 · 0 comments
Open

Genericize Build Functionality #342

michaeltlombardi opened this issue Feb 11, 2022 · 0 comments

Comments

@michaeltlombardi
Copy link
Contributor

The functionality in PCT which enables a user to turn a template into a package should be genericized for reuse in PRM's tool building functionality.

michaeltlombardi added a commit that referenced this issue Feb 11, 2022
Prior to this commit, the only implementation of an interface
for the ConfigProcessor lived in the install package; moreover,
this interface only included the ProcessConfig function.

This commit creates a new public package, config_processor, which
contains only a single interface: ConfigProcessorI.

This interface includes both the ProcessConfig function and the new
CheckConfig function. This will allow external libraries/tools  to
re-use our code so long as they implement a processor for their own
needs which can perform those tasks.

This commit does **not** implement or otherwise alter the private
configuration processor (pct_config_processor) or any other files.
michaeltlombardi added a commit that referenced this issue Feb 11, 2022
Prior to this commit, functional logic for validating a config file
lived not in the private processor (pct_config_processor) but in the
private build package as a private function.

This commit adds the CheckConfig function to the private processor
as a public function so that the private processor becomes a valid
implementation of the ConfigProcessorI interface.

It slightly refactors the implementation from the build package in
this transfer, as the logic for reading a configuration file is
already defined in a private function for the private processor. It
also ensures that the full path to the configuration file being checked
is returned in any error messages; the prior implementation only
specified 'pct-config.yml' which is neither generic for use in other
libraries/tools, nor specific if the caller is pointing to a config
anywhere but in the current working directory.

This commit **does not** replace any upstream package usage to point
to the new function, it **only** makes the private processor a valid
implementation of the ConfigProcessorI interface.
michaeltlombardi added a commit that referenced this issue Feb 11, 2022
Prior to this commit, the private build package implemented its own private
function to validate if a template config file prior to packaging it.

This commit:

1. Updates the private build package to append a new value to its struct,
   ConfigProcessor, which must be a valid ConfigProcessorI interface.
2. Updates the private build package to replace calls to its own private
   checkConfig() function with calls to ConfigProcessor.CheckConfig.
3. Removes the private checkConfig() function from the private build
   package as it is no longer needed or used.
4. Updates the unit tests for the private build package to reflect the
   modified implementation of ConfigProcessor.CheckConfig()
5. Updates the build command itself to load the private processor.
michaeltlombardi added a commit that referenced this issue Feb 11, 2022
Prior to this commit, the install package created its own interface
for ConfigProcessorI so that it could safely reference the
ProcessConfig() function.

This commit updates the install package to point instead to the
ConfigProcessorI interface defined in the public config_processor
package.
michaeltlombardi added a commit that referenced this issue Feb 12, 2022
Prior to this commit, functional logic for validating a config file
lived not in the private processor (pct_config_processor) but in the
private build package as a private function.

This commit adds the CheckConfig function to the private processor
as a public function so that the private processor becomes a valid
implementation of the ConfigProcessorI interface.

It slightly refactors the implementation from the build package in
this transfer, as the logic for reading a configuration file is
already defined in a private function for the private processor. It
also ensures that the full path to the configuration file being checked
is returned in any error messages; the prior implementation only
specified 'pct-config.yml' which is neither generic for use in other
libraries/tools, nor specific if the caller is pointing to a config
anywhere but in the current working directory.

This commit **does not** replace any upstream package usage to point
to the new function, it **only** makes the private processor a valid
implementation of the ConfigProcessorI interface.
michaeltlombardi added a commit that referenced this issue Feb 12, 2022
Prior to this commit, the private build package implemented its own private
function to validate if a template config file prior to packaging it.

This commit:

1. Updates the private build package to append a new value to its struct,
   ConfigProcessor, which must be a valid ConfigProcessorI interface.
2. Updates the private build package to replace calls to its own private
   checkConfig() function with calls to ConfigProcessor.CheckConfig.
3. Removes the private checkConfig() function from the private build
   package as it is no longer needed or used.
4. Updates the unit tests for the private build package to reflect the
   modified implementation of ConfigProcessor.CheckConfig()
5. Updates the build command itself to load the private processor.
michaeltlombardi added a commit that referenced this issue Feb 12, 2022
Prior to this commit, the install package created its own interface
for ConfigProcessorI so that it could safely reference the
ProcessConfig() function.

This commit updates the install package to point instead to the
ConfigProcessorI interface defined in the public config_processor
package.
michaeltlombardi added a commit that referenced this issue Feb 14, 2022
Prior to this commit, the private build package contained
several hard-coded references to pct-config.yml preventing
this package from becoming truly generic.

This commit removes the hard-coded config file name by
extending the Builder struct to include the ConfigFile
key for that value instead.

This commit updates tests and the build command to reflect
this refactor.
michaeltlombardi added a commit that referenced this issue Feb 14, 2022
Prior to this commit, the build package containing the Build() function for
turning a config file with a content folder into an installable tar.gz was
private, necessitating other libraries and tools to reimplement this logic.

This commit takes the private build package and makes it public, now that it
has no private package dependencies or hard-coded logic specific to PCT.
michaeltlombardi added a commit that referenced this issue Feb 14, 2022
Prior to this commit the `build.Build()` function took `templatePath` as
the input for the directory to attempt to package and referenced the
"template" in both comments and messages.

This commit updates the function to instead take `sourceDir` as the
input for the directory to attempt to package and removes all references
to "template" from comments and messages, replacing it where coherent
with "project"

This further genericizes the build package for external library usage.
michaeltlombardi added a commit that referenced this issue Feb 14, 2022
Prior to this commit, the cobra `build` command used package variables
and instantiated a PCT-specific `build` command in the `CreateCommand()`
function. Any other cobra applications wanting to use the now-generic
functionality from the public `build` package would need to reimplement
this command wholly themselves as it hard-codes to PCT's packaging
paradigm (i.e. it references "templates", expects a `pct-config.yml`,
and instantiates the private PCT `ConfigProcessor`).

This commit genericizes the `build` command by:

1. Replacing the package variables with a `BuildCommand` struct,
   declaring a `BuildCommandI` interface, and updating the functions
   (`CreateCommand()`, `preExecute()`, and `execute()`) to be attached
   to the new `BuildCommand` struct.
2. Replacing references in the `build` command's reference doc help text
   and error/info messaging, updating default language to "project" and
   extending the `BuildCommand` struct to include defining a
   `ProjectType` to clarify those docs/messages (i.e. "Builds a package
   from the template project" for PCT where `ProjectType` is set in the
   struct as `template`).
3. Moving the instantiation of the struct to `main` where it  defines
   the `ProjectType` as `template` and instantiates the `build.Builder`
   struct, passing in the private `PctConfigProcessor`.

During testing for this change, I noticed that the unit tests for the
`build` command did not mock the `build.Builder`; this was because the
`CreateCommand()` function instantiates that struct inside itself.
Therefore, the unit tests were _actually_ trying to build packages.

This commit reworks and simplifies those tests so that they use a new
mock `Builder` instead of functionally (and without documentation)
running integration tests for the `build` package.
michaeltlombardi added a commit that referenced this issue Feb 14, 2022
Prior to this commit, the cobra `build` command used package variables
and instantiated a PCT-specific `build` command in the `CreateCommand()`
function. Any other cobra applications wanting to use the now-generic
functionality from the public `build` package would need to reimplement
this command wholly themselves as it hard-codes to PCT's packaging
paradigm (i.e. it references "templates", expects a `pct-config.yml`,
and instantiates the private PCT `ConfigProcessor`).

This commit genericizes the `build` command by:

1. Replacing the package variables with a `BuildCommand` struct,
   declaring a `BuildCommandI` interface, and updating the functions
   (`CreateCommand()`, `preExecute()`, and `execute()`) to be attached
   to the new `BuildCommand` struct.
2. Replacing references in the `build` command's reference doc help text
   and error/info messaging, updating default language to "project" and
   extending the `BuildCommand` struct to include defining a
   `ProjectType` to clarify those docs/messages (i.e. "Builds a package
   from the template project" for PCT where `ProjectType` is set in the
   struct as `template`).
3. Moving the instantiation of the struct to `main` where it  defines
   the `ProjectType` as `template` and instantiates the `build.Builder`
   struct, passing in the private `PctConfigProcessor`.

During testing for this change, I noticed that the unit tests for the
`build` command did not mock the `build.Builder`; this was because the
`CreateCommand()` function instantiates that struct inside itself.
Therefore, the unit tests were _actually_ trying to build packages.

This commit reworks and simplifies those tests so that they use a new
mock `Builder` instead of functionally (and without documentation)
running integration tests for the `build` package.
petergmurphy added a commit that referenced this issue Feb 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant