worried-salesclerk-37834
08/24/2021, 2:47 AMlambdex
backend? Or would you prefer that a new backend gcpcloudfunction
be created and duplicate code would exist, but it would be easier to allow for the different types to diverge? I think the second would also prevent a breaking change since the backend name would change?hundreds-father-404
08/24/2021, 4:56 AMhappy-kitchen-89482
08/24/2021, 5:25 AMwitty-crayon-22786
08/24/2021, 4:23 PMworried-salesclerk-37834
08/24/2021, 6:38 PMhappy-kitchen-89482
08/24/2021, 9:11 PMhundreds-father-404
08/24/2021, 9:13 PMworried-salesclerk-37834
09/01/2021, 11:26 PMhundreds-father-404
09/01/2021, 11:37 PMAmazing! It looks like this isn't sharing any code with the awslambda code, which it should and can (e.g. so you don't have two lambdex subsystems)
To factor that out, you would find a common home for this. Maybe backend/python/lambdex? Then, update those two backends to import code from there
A good starting point would be moving Lambdex to maybe backend/python/lambdex/subsystem.py, and its lockfile to lambdex/lockfile.txt
Ok, I didn't know how coupled/uncoupled we wanted it to be. Is there anything magical about the "backend" package? If a user activates the "gcpcloudfunction" backend, will they also get the lambdex stuff?
Definitely we do want as much DRY as we can for internal code and for any public APIs that are shared (i.e. the lambdex subsystem). That's one of the cool parts of the engine is how easy it is to refactor code like this
Activating a backend package will activate everything in its register.py. In gcpcloudfunction's case, it would activate the new target type, the package rule, and Lambdex for you. If a user also activates awslambda, it will activate Lambdex again but that's a no-op because it only needs to be registeredtwiceonce
There's also an integration test that makes sure activating only gcpcloudfunction will work and that it doesn't expect the user to have activated other backends