Skip to content

refactor: split packageinfo.WritePackageInfo into one function for modules and one for packages#363

Open
hartblanc wants to merge 13 commits into
please-build:masterfrom
hartblanc:write_module_info
Open

refactor: split packageinfo.WritePackageInfo into one function for modules and one for packages#363
hartblanc wants to merge 13 commits into
please-build:masterfrom
hartblanc:write_module_info

Conversation

@hartblanc

Copy link
Copy Markdown

This change is a refactor.
It is in preparation for fixing issues #352 - #362.

I have attempted to keep the individual commits as small as possible. They should be significantly easier to review than the whole PR.

I have added some tests early on to reduce the risk of regressions with the refactoring. I have avoided adding test cases where the behaviour is currently buggy (e.g. I did not include a test case for external test packages given #362).

The primary aim of the refactor is to separate the codepaths for writing packageinfo for modules (i.e. the module_info command of please_go) and for stand-alone packages (i.e. the package_info command of please_go).

module_info is called for go_module and go_stdlib targets. package_info is called for all other types of targets.

These two groups of targets have very different characteristics:

  1. module_info targets have many packages for a single target, whereas package_info targets should only return a single package.
  2. module_info rules are only ever depended on, they do not have sources that need to be queried by the package driver directly. They are only ever included as dependencies.
  3. module_info rules have their source code primarily built outside of please by standard go tooling. Therefore, they adhere to standard go package constraints that please does not enforce (e.g. one package per directory). They also use features of the go build tooling that please does not support for other types of targets (module vendoring).

These differences in characteristics heavily influence the way that I intend to handle the two types of packages when addressing the issues I have raised. I also believe the co-location of these two codepaths has contributed to the bugs that are present today (e.g. when attempting to introduce tests for package_info targets we accidentally introduced some bugs in the module_info targets).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant