https://serverless-stack.com/ logo
Join Slack
Powered by
maybe I’ll sound too silly suggesting something th...
# help
j
maybe I’ll sound too silly suggesting something that’s unreasonable, but would it be possible for the sst script to write an environment variable that’s going to be used by other process? (Namely, whatever executing the python code in my case). The use case is this: an environment variable is used to pass a 
bucketName
from the CDK script to the lambda function. However, when that’s executed locally, the environment definition in 
function.environment
doesn’t get applied (only when this is deployed) and thus I’m stuck with my env vars defined locally. Therefore, my questions are 1) should SST be defining those env vars instead? 2) if not, would you guys have any suggestions on how to make the stack output available to my python code?
I guess this could only be done after synthesizing the app, right? I probably need to get more educated on how the cdk/sst code is used by the app lifecycle to know how to plug that in cdk/sst
m
Have you looked into cdk context? Sounds like it might fit your use case. https://docs.aws.amazon.com/cdk/latest/guide/context.html
r
were you able to find a solution to this @José Ribeiro?
d
@José Ribeiro maybe this can add some thoughts? we have alot of env vars in a local 
.env
that we use. it's a Nodejs module that reads from the file and adds it to our environment variables. and likewise, when we deploy, i make sure our CI pipeline (Seed) has their own corresponding set of env variables.
it sounds like your deployment system is missing the variables.
j
haven’t looked at this again yet — but just wanted to make it clearer that the use case here is: the app needs the name of a s3 bucket or sns topic which will only be defined after CDK resolves tokens within the stack. This is ok when deploying the functions themselves, because the environment variables definition is also part of the CDK script and thus will be resolved at the same time. However, I’m trying to figure out a way of getting those in local runtime (apart from adding the resource to the stack outputs and then command/pasting that). does that make sense?
d
why are the values available in regular deployment but not available in your local env? i'm trying to understand what's different in your use-case here versus mine where i also create buckets, queues, topics and share those among the lambdas in both local and prod. the same set of buckets/queues/resources will be created per env.
f
@José Ribeiro, I’m not too clear what do 
CDK script
and 
local runtime
refer to. This is what I think you meant, please correct me if i’m wrong. Imagine this is ur setup:
Copy code
const bucket = new sst.Bucket(this, "MyBucket");
const fn = new sst.Function(this, "MyFunction", {
  handler: "src/lambda.main",
  environment: {
    BUCKET_NAME: bucket.bucketName,
  }
});
And are you saying that on 
sst deploy
, 
BUCKET_NAME
gets resolved correctly. But on 
sst start
, 
BUCKET_NAME
shows as a token value in ur local function?
j
correct, this is what I meant — on 
sst start
, `BUCKET_NAME`is not picked up by my local function. It doesn’t show as a token value, it’s just missing altogether
f
Oh, that might be a bug. This is happening for python runtime?
BUCKET_NAME
should resolve to the actual value even locally, this is likely what @Dennis Dang is seeing with Node runtime.
j
yup, can confirm this in the python runtime
f
I see. Lemme give it a quick try.
j
ok, thanks!
f
You are accessing it like this in the code right?
Copy code
os.environ['BUCKET_NAME']
j
yup, I’m accessing them from 
os.environ
f
yup testing it rn
@José Ribeiro hmm this works for me:
Copy code
// MyStack.js
const api = new sst.Api(this, "Api", {
  defaultFunctionProps: {
    srcPath: "src",
    runtime: lambda.Runtime.PYTHON_3_8,
    environment: {
      TABLE_NAME: table.tableName,
    },
  },
  routes: {
    "GET /": "handler.main"
  },
});
Copy code
// handler.py
import os

def helloA(event, context):
  return {
    "statusCode": 200,
    "body": os.environ["TABLE_NAME"]
  }
And this is running inside 
sst start
I guess can you check if the environment variables are set in the Lambda console.
j
🤡 was using 
cache.bucketName
instead of 
cache.s3Bucket.bucketName
there was nothing there, so obviously it looked like it was empty
f
Maybe you are using an older version of SST? 
cache.bucketName
should work.. that was put in a couple of releases back
j
hmm I’m using 
v0.24.0
. But I could also have done something else wrong.
f
Sorry @José Ribeiro, I lied. 
cache.bucketName
isn’t there. I’m going to add it into the release today.
j
no sweat, thanks Frank!
f
Aight, added 
cache.bucketName
and 
cache.bucketArn
in v0.25.1
3 Views
Open in Slack
PreviousNext
Powered by