Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: generate stubs for FTL modules #1106

Merged
merged 27 commits into from
Mar 21, 2024
Merged

feat: generate stubs for FTL modules #1106

merged 27 commits into from
Mar 21, 2024

Conversation

matt2e
Copy link
Collaborator

@matt2e matt2e commented Mar 18, 2024

ftl build and ftl dev now accept a list of external library directories which need stubs generated of the ftl modules it uses

eg:

ftl dev build examples/go --external examples/go/lib

This example finds all go modules in the go folder as well as treating go/lib as an external library

@alecthomas alecthomas mentioned this pull request Mar 18, 2024
@matt2e matt2e force-pushed the matt2e/stub-ftl-modules branch from 83f55fe to 198e0e2 Compare March 20, 2024 02:48
gatherShemas(moduleSchemas, modules, modules[dep], out)
if dep != "builtin" {
depModule, ok := e.projects[dep]
// TODO: should we be gathering schemas from dependencies without a project?
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Need to ask someone about this

@matt2e matt2e force-pushed the matt2e/stub-ftl-modules branch from 0e2e55b to 6aa1e3b Compare March 20, 2024 05:42
// It is used to:
// - build the dependency graph
// - map changes in the file system to the project
type ProjectKey string
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit iffy on how wise it was to do it like this. It extends to a Project's Dependencies []ProjectKey.

I imagine one day we'd want to make a ModuleConfig.Module into a ModuleName type?
Projects can only depend on Modules (not ExternalLibraries), but they are all accessed via buildengine's map[ProjectKey]Project, and declaring all dependencies as ProjectKeys lessens the amount of recasting

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you, but having it in Dependencies definitely doesn't make sense as an external lib can't be a dependency.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weren't you getting rid of ProjectKey?

buildengine/build.go Outdated Show resolved Hide resolved
buildengine/build.go Outdated Show resolved Hide resolved
buildengine/discover.go Outdated Show resolved Hide resolved
buildengine/discover.go Outdated Show resolved Hide resolved
buildengine/project.go Show resolved Hide resolved
buildengine/project.go Outdated Show resolved Hide resolved
// It is used to:
// - build the dependency graph
// - map changes in the file system to the project
type ProjectKey string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you, but having it in Dependencies definitely doesn't make sense as an external lib can't be a dependency.

@@ -8,34 +8,37 @@ import (

// TopologicalSort returns a sequence of groups of modules in topological order
// that may be built in parallel.
func TopologicalSort(graph map[string][]string) [][]string {
modulesByName := map[string]bool{}
func TopologicalSort(graph map[ProjectKey][]ProjectKey) [][]ProjectKey {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to above, ProjectKey doesn't make semantic sense here, and doesn't ensure enough type safety. I'd probably either back it out or split the types even further:

//sumtype:decl
type ProjectKey interface { projectKey() }

type ModuleKey string
func (ModuleKey) projectKey() {}

type ExternalLibraryKey string
func (ExternalLibraryKey) projectKey() {}

This allows either to be used, or only one.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll back out ProjectKey somewhat, i think that's the best thing for now.
I was also thinking along the lines of having separate types, but figured to do a fully thought through ModuleKey/ModuleName type would be a lot farther reaching, and beyond the current scope of what I wanted to change.

@matt2e matt2e marked this pull request as ready for review March 21, 2024 03:07
Copy link
Collaborator

@alecthomas alecthomas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but please add some tests.

"testing"

"github.com/alecthomas/assert/v2"

"github.com/TBD54566975/ftl/common/moduleconfig"
"github.com/TBD54566975/ftl/internal/log"
)

func TestDiscoverModules(t *testing.T) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a test that includes an external library that imports one of the existing ftl modules in testdata.

// It is used to:
// - build the dependency graph
// - map changes in the file system to the project
type ProjectKey string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weren't you getting rid of ProjectKey?

@matt2e matt2e force-pushed the matt2e/stub-ftl-modules branch 2 times, most recently from c7f19e6 to df13243 Compare March 21, 2024 03:27
@matt2e
Copy link
Collaborator Author

matt2e commented Mar 21, 2024

@alecthomas I kept ProjectKey but just for getting projects via the key (engine.projects map[ProjectKey]Project{}) but removed the other uses when we really meant module name (dependencies, maps of schemas etc).

@matt2e matt2e force-pushed the matt2e/stub-ftl-modules branch 2 times, most recently from 545c008 to 30108a4 Compare March 21, 2024 05:14
@matt2e matt2e force-pushed the matt2e/stub-ftl-modules branch from 30108a4 to 372c565 Compare March 21, 2024 05:21
@matt2e matt2e merged commit 5eb0b3f into main Mar 21, 2024
11 checks passed
@matt2e matt2e deleted the matt2e/stub-ftl-modules branch March 21, 2024 05:24
@@ -0,0 +1,11 @@
package lib
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice.

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.

2 participants