Support for multiline strings

[christophe-riolo]

Hello, it seems like decouple does not currently support the variables split on multiple lines

# .env file
FOO="foo
bar"

# python
 from decouple import config

>>> config('FOO')
 '"foo'

Of course for a small example like that I could write `FOO="foo\nbar" but for an RSA key it becomes long.
It seems that the issue is that the config reader only checks the lines with the = sign

[glnnlhmn]

They just recently added multiline support to the .env file motdotla/dotenv#486. So I can see how this came up.

[MarsianMan]

This caught me by surprise recently.

[henriquebastos]

Hi. Currently, I have no plan to include support for multiline strings. I don't know of enough use cases that will make this desirable. As a workaround for RSA keys, I'd recommend pointing to a file so the filesystem will make sure only authorized processes can access it.

[MarsianMan]

A file vs environment variable are completely different and not equivalent. The proposed suggestion is working around a library's quirks rather than the library being helpful. I'll look around for a different library. If anyone has suggestions, it would be appreciated.

[MarsianMan]

As a a workaround, maybe we can have a property that mimics the above? I.e. setting the content of the .env key SOMETHING to the filepath and then use python config to load that content into the environment variable.

SOMETHING=path/to/file

and in the python

content = config('SOMETHING', from_file=True)

[henriquebastos]

It's not about being useful to a particular need. But to connect needs aligned to the library's purpose and evolve its capabilities.

It is not safe to store sensitive data in env vars. So the use case of supporting the content of an RSA key is not a valid one for a library focused on loading data from an env var with a fallback of a .env text file.

Of course, we all have corner cases and trade-offs to manage. One can and should pursue a particular solution. That is precisely why I make most of my tools open source and encourage forks.

[MarsianMan]

It is not safe to store sensitive data in env vars.

Many secret vaults implementations and platforms do this, especially in the cloud world. Which is really why I was say env variable is NOT the same as a file, but the contents (as a long possibly multi-line string) CAN BE the same. I have seen both where the env variable was actually an injected secret (contents of a file, but NOT interacted with as a file) or a path to the file. Your needs depend on your toolset, which is often out of your control.

MANY systems in the linux world using environment variables to store credentials. This used to (and still is) an extremely common practice. Look at AWS (as one of the biggest clouds) which does this constantly with their service credentials and tokens. AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for the both for their CLI and their SDK

I won't argue with you philosophically, but the real world practices do not match your idealistic statement.

[henriquebastos]

Sorry if I sounded philosophical. I was just trying to be polite. Again, that is a non-issue for the purpose of this library, and it won't be implemented. You can store a whole book if you want with a simple base64 encoding or fork it.

[MarsianMan]

You can store a whole book if you want with a simple base64 encoding or fork it.

Base64 encoding properties defeats the purpose of this library because it literally is a work around for the core goal that this module is trying to solve. If you suggest that I write custom code, why bother using libraries, why not just ask me to use the flapping of butterfly wings? 🤷🏾

Goals as defined by the README:

1. store parameters in ini or .env files;

Does not let me store multi-line parameters in these files. They didn't stop being a parameters just because a newline exists in the content. FAIL

2. define comprehensive default values;

PASS

3. properly convert values to the correct data type;

Does not convert multiline strings to correct data type because it truncates data: FAIL

4. have only one configuration module to rule all your instances.

Author says to use a different library: FAIL

Of the 4 project goals, your statement does not align to 3 of them.

Again, that is a non-issue for the purpose of this library, and it won't be implemented....Sorry if I sounded philosophical. I was just trying to be polite.

Your statement of "I don't care, works for me, GTFO," Sounded neither philosophical, nor open minded, nor polite.

It is my hope that pointing out a missing common need by users of this library and how that aligns project goals changes your mind. But given the lack of interest or meaningful engagement from the initial response, I doubt this changed your mind; this will be my last post on the topic. If you change your mind, let me know.