project-flogo/core

Contributions and go.mod

Closed this issue · 7 comments

fm-tibco commented

Should we prescribe that each contribution have its own go.mod? For example in contrib should we have separate go.mods instead of one top-level one? What are the advantages/disadvantages of both approaches?

On thing about requiring individual ones, coding for a contrib can be more straight forward. For example as part of an activity tutorial, we can tell people to create always create go.mod, instead of having a bunch of ambiguous information about proper placement of thier go.mod depending on their repo structure. We can also create a "gen" cli plugin that can create scaffolding for a contribution that creates its go.mod as well.

I just want to get everyones thoughts and possible consensus I guess there are a couple of questions:

  1. Do individual go.mods make sense?
  2. In our current repos with multiple contribs, should we create individual go.mods
  3. In a contrib creation tutorial or gen tool, should we always create a go.mod for the individual contrib.
  4. If we think this is the way to go, should this be recommended or required behavior?

Thoughts? @mellistibco @pointlander @debovema @vijaynalawade @skothari-tibco

vijaynalawade commented

@fm-tibco : As far as contrib repo is concerned, it is just a placeholder for TIBCO contributions. I think module per repo makes sense for one or more related packages. Since Flogo contributions are self contained and small, I feel module per contribution would make more sense. Though I feel, tagging of the repo could be tricky as each change in activity/trigger would need a new tag.

skothari-tibco commented

I don't think we need individual go.mod in current repos. About the question of individual go.mod it is simpler and also makes managing repos easier. But if there are multiple activities/ triggers somewhere around like 4-5 or more using similar dependencies it would be easier to club to have only have go.mod for those. So I think it's pretty opinionated. However we can recommend a single mod file for single repo.

debovema commented

I think having a go.mod per contribution is the best solution independently of the number of contributions in a Git repository.
On a development point of view, it does not change much as all the contributions, each having its go.mod, will be tagged together.
On the user point of view however, it allows to use two contributions from the same Git repository with two different Go modules versions.

For current repository (contrib) no need to do a big bang refactoring.
For contributions to be generated by gen tool, let's include a go.mod per contribution from the start.

fm-tibco commented

I am for the per contribution. I don't know if it will be too much of a big deal to add go.mods to the project-flogo/contrib contributions... I think people might look at that as an example of best practices.

On a side note, are you guys fans of checking in the go.sum. II'm not, just curious what people think.

  • 👍1
debovema commented

I think go.sum files are a pain to check in but we have to do it.
It ensures that transitive dependencies will be verified against their crypto hash and that they will be the same as the one used by the releaser of the contrib.
If we want to avoid security holes of npm (and we want!), please check in the go.sum files :)

  • 👍1
  • 😄1
vijaynalawade commented

I agree with @fm-tibco. Other developers will definitely use TIBCO contribs as example or modify them for their own use cases.