Giters

project-flogo / contrib

Core Flogo activities, triggers and functions that are useful across the various event-driven action types.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Should all contributions have their own go.mod file ?

debovema opened this issue · comments

commented

Context

In Flogo, when we want to install a contribution (github.com/project-flogo/contrib/activity/log for instance) in an application we run:

flogo install github.com/project-flogo/contrib/activity/log

Currently, this command does a go get -u github.com/project-flogo/contrib/activity/log (see https://github.com/project-flogo/cli/blob/99f31dabada136e9cddc2e5202d97011a7a315bc/util/mod.go#L80).

By design, go get cannot fetch a specific revision (tag or branch), but only HEAD (master).

Hence we cannot do something like:

flogo install github.com/project-flogo/contrib/activity/log@v0.9.0

Instead we could use go mod edit in the flogo install command instead of go get:

go mod edit -require github.com/project-flogo/contrib/activity/log@v0.9.0

as tried at https://github.com/square-it/cli/blob/1e044ca3c17e14913e3914700aa4210e55c4292d/util/mod.go#L82.

Issue

However this will lead to this error:

go: finding github.com/project-flogo/contrib/activity/log v0.9.0
go: errors parsing go.mod:
/workspaces/flogo/simple-app/src/go.mod:4: invalid module version "v0.9.0": missing github.com/project-flogo/contrib/activity/log/go.mod at revision 680ebf186e58

That's logic since the go.mod file for this contributions repository lives at github.com/project-flogo/contrib, not at github.com/project-flogo/contrib/activity/log

Solutions

1. use separate contribution import path and contribution module import path

Using a more verbose commands such as:

flogo install github.com/project-flogo/contrib@v0.9.0 github.com/project-flogo/contrib/activity/log

flogo install -module github.com/project-flogo/contrib@v0.9.0 -contrib github.com/project-flogo/contrib/activity/log

the Flogo CLI could use the module import in go.mod and the contribution import path in imports.go.

another more compact representation allowing multiple contributions installation at once

flogo install github.com/project-flogo/contrib@v0.9.0/activity/log github.com/project-flogo/contrib@v0.10.0/activity/rest

2. make all contribution (activities, triggers, ...) have their own go.mod file

If we don't want to modify the CLI behaviour, we can also require that any contribution must have its own go.mod file. For instance, go.mod for the github.com/project-flogo/contrib/activity/log activity would look like:

module github.com/project-flogo/contrib/activity/log

require (
	...
)

3. Create a new syntax for Flogo imports

Described in PR project-flogo/cli#32

Depends on PRs:

commented

Can you please confirm that go get by design doesn't pull a specific tag? For me it works perfectly fine, and it does pull the specific tag I need. Eg go get -u github.com/project-flogo/contrib@v0.9.0-alpha.3

commented

Sorry I meant by design when not working with modules which is the case if we do
go get github.com/project-flogo/contrib/activity/log as it is done currently in the Flogo CLI.
When using the Go import path instead of the Go module path we cannot add a version.

commented

I'm a bit confused about meant by design when not working with modules. If you are facing the following issue go: finding github.com/project-flogo/contrib/activity/log v0.9.0 , It is because v0.9.0 doesn't exist. It is v0.9.0-alpha.3

commented

I rewrote the command with v0.9.0 but tested with existing version.

The problem is not the version but the fact that the path points to a place on the repository where there is no Go module (go.mod).

In fact using github.com/project-flogo/contrib@v0.9.0-alpha.3 will work whereas github.com/project-flogo/contrib/activity/log@v0.9.0-alpha.3 will not.

I did a test in a Docker container started with:

docker run --rm -it golang:1.11.5 bash

Working:

mkdir /tmp/test
cd /tmp/test
go mod init test
go mod edit -require github.com/project-flogo/contrib@v0.9.0-alpha.3
go mod verify

Failing:

mkdir /tmp/test
cd /tmp/test
go mod init test
go mod edit -require github.com/project-flogo/contrib/activity/log@v0.9.0-alpha.3
go mod verify
commented

I updated the issue with a third solution implying modifications mainly in CLI and minor ones in core but none to contrib.
Description can be found in project-flogo/cli#32.

If you can have look with @fm-tibco @mellistibco.

commented

@debovema I see that you did go mod edit require and I indeed got the error. But can you please tell me why go get is not a good way? It seems to pull the specified HEAD/tag/ branch correctly.

commented

I might have been mistaken by the pre-modules behaviour of go get and the original implementation. I see in a recent commit in project-flogo/cli that you did something to separate the version from the import path (util.ParseImportPath) which is what I did in project-flogo/cli#32. So now specific versions can be retrieved with go get.

However I remain convinced that using "go mod edit -require" is better than "go get".
That's declarative model vs imperative model.
Resulting go.mod are less verbose and semantically better.
Validation (using go mod verify) can be performed at the end of install command which is useful when several contributions are installed in the same command.

commented

Should be closed since project-flogo/cli#32 has been merged.

However considering the newly created repositories https://github.com/project-flogo/azure and https://github.com/project-flogo/eftl which will be the home for triggers and activities for Azure and eFTL if I'm not mistaken, I'm wondering whether these repositories should be prefixed by something to distinguish these repositories from other transversal repositories ("core", "cli", "flow", "microgateway", ...) ?

Ideas:

@mellistibco : since you created the aforementioned repositories what do you think ?
@fm-tibco : what do you think also ? IMO, the choice of the prefix is related to project-flogo/cli#43.

commented

@debovema good question. I think we can probably accomplish some level or organization just by using GitHub tags and of course, the individual contribs will be in the showcase, as well, which should also help some.

We've also pinned the primary repos, to help make them a bit more obvious to find on GitHub when browsing the project-flogo org.

commented

My concern was more about the names of the repositories being "nude". I mean with no clue they are linked to the Flogo project.
As a developer advocate for Flogo you naturally see all repositories from a Flogo-centric point of view (not a reproach).
But we need to think about developers in the wild. For instance, if they want to get involved in the repository of Azure contributions for Flogo: when they fork the repository github.com/project-flogo/azure to their personal / organization repository, how will they know this "azure" repository is related to Flogo ? (I mean at first glance, not by looking into the repository).
I was not really fan of the core / flow / cli / ... "nude" repositories as well. These ones would be harder to rename but new ones should have better naming conventions IMHO.

I thought about a new prefix: flogomod- since it seems that the rule of thumb a repository == a Go module will apply.

commented

hmm, good point @debovema let's think of a few other alternatives, i mean i suppose the same applies for almost all of the repos, no? core, flow, etc...

commented

Yes it applies to other repositories too of course.
The price to rename those is a little higher than the fresh newly created ones but it is still possible IMO.
I know it's maybe not too priority though ;)
What are the alternatives you are thinking about ?