Spaces:

---

Langflow

/

Langflow

like 1.15k

Building

To provide more info, I was hoping I could provide the needed API keys somewhere in this code:

from langflow import load_flow_from_json

flow = load_flow_from_json("Basic Chat.json")
# Now you can use it like any chain
flow("Hey, have you heard of LangFlow?")

Hi @mehran ,

You can do it like the code below or load the env variables before executing load_flow_from_json.

import os
from langflow import load_flow_from_json

os.environ["OPENAI_API_KEY"] = "my_key"

flow = load_flow_from_json("Basic Chat.json")
# Now you can use it like any chain
flow("Hey, have you heard of LangFlow?")

Thanks, @gustavopoa .
While your answer is correct, it's exactly what I was afraid of. This approach is a 101 programming mistaken. Using global variables is wrong. I just wish there were more software engineers involved in projects like this.
In any case, thanks for your answer

Hi @mehran ,

This is an approach from LangChain and not from LangFlow, where you can load all the envs or pass them as a parameter in each call.
But just like you, I am also curious to know why they did it this way :-)

https://python.langchain.com/en/latest/getting_started/getting_started.html

https://github.com/hwchase17/langchain/blob/master/langchain/llms/openai.py#L214

Feel free to help us improve LangFlow and LangChain.

Cheers.

Hi @gustavopoa ,

Please forgive me if my criticism came across rude. That was not my intention. And I understand that this design was imposed on LangFlow by LangChain. It's just that when you see some library so well-thought, you expect them to be perfect in all aspects.

Great job and thank you.

Hey mate,

All observations are welcome, thank you for getting involved. 👍

Stay tuned for the next updates, we will have new features.

If you find anything else, please let us know.

Cheers.

if you need to use API keys or other sensitive data in your code, I can advise you the following approach to avoid storing keys explicitly in your code.

Create a .env file in the root folder of your project (if you don't have one). In this file, you can store your API keys and other sensitive data as "name=value" pairs. For example:

OPENAI_API_KEY=my_key

Install the python-dotenv package so that your code can automatically load variable values from the .env file. You can install it with the pip install python-dotenv command.
In your code where you need to use the API key, import the dotenv module and call load_dotenv() to load variables from the .env file. You can then retrieve the value of the key with os.getenv(). For example:

import os
from dotenv import load_dotenv
from langflow import load_flow_from_json

load_dotenv() # Load variables from .env file

api_key = os.getenv("OPENAI_API_KEY") # get API key value from environment variable

flow = load_flow_from_json("Basic Chat.json")
‘now you can use it like any chain’
flow("Hey, have you heard of LangFlow?")

This way you can store sensitive data, like API keys, in a separate .env file that won't get added to version control, and use it in your code without storing it explicitly in the code itself.

Hi @yevhen27007 ,

Correct, exactly what I mentioned here.

Cheers.

I think there's been a misunderstanding here. Using the environment variables or hard coding them are not the only options. I understand that it's much better to use environments over hard coding them but there are other approaches even better than both. I was suggesting accepting the API keys as an input argument to the class/function that needs them instead of using global variables (that's what environment variables are, global variables).

The problem with using environment variables can easily be explained in this scenario:

Let's say that I have a use case where I need to use two API keys (whatever that use case might be). When you are forcing developers to use environment variables to pass the API keys, there's no safe way of using more than one API key. But if you let them pass it as an input argument, they can instantiate two different objects (or call the function twice) with different API keys as their input arguments. I hope I managed to convince you that using environment variables is a bad practice and should not be followed.

where is this going = any progress?

i'm looking over at flowwise and the way they handle api keys is definitely an improvement over the langflow approach.... i would list it as a "killer feature" in fact given the improvement it affords over UX & security