Simplicity and Stability vs Advanced Features

[jonnyhsu]

This is one of my favorite projects because of it's ease of use, and because it always just works, so thank you to all the contributors and maintainers, especially @joke2k and @sergeyklay for the effort.

There's an topic that's come up implicitly in several pull requests but hasn't been discussed directly, so I'd like to present my opinion as well as start a forum for discussion. The topic is Simplicity and Stability vs Advanced Features. Specifically, I'm referring to what constitutes valid syntax in an env file.

On the one hand, I see the value in adding advanced features like variable expansion, inline comments, etc. On the other hand, features like this reduce the simplicity of the project, and I find the simplicity of the syntax one of the best parts. To the left of the = is the variable name, and to the right is the value. No need to worry about escape characters, inline comment characters, quoted strings, or any other complications. It just works.

This is a fairly popular project which is downloaded over 60,000 times a day (https://pypistats.org/packages/django-environ). I'm using it in production, and I'm sure many others are as well, so changes have an effect on a lot of people, especially if new requirements are introduced (for example, the need to quote hash characters in #475). As this project continues to be used, there will certainly be a continuous stream of requests to expand the feature set. My preference is that this project stays small, simple, and easy to use.

It would be great to hear what others have to say on this topic.

[sergeyklay]

Hi @jonnyhsu,

First and foremost, both @joke2k and I are incredibly pleased to hear that the time we've invested in this project has been worthwhile. It's heartwarming to know that there are supporters who appreciate its features and design. Thank you!

I believe there are several core strategies for the development of an OpenSource project, at least those that we can discuss openly. One strategy involves boldly accepting changes and adapting to user needs. This approach inevitably leads to situations where not all users find the changes beneficial. Another strategy is to be as conservative as possible, working with most existing configurations while offering additional options. This isn't ideal either, as there are users who desire more progressive development and extra features. There are other strategies as well, but they are mostly derivatives of these, so I won't mention them here.

I'm deeply convinced that collaborative feedback, in any form, is the deciding factor in choosing any strategy. The most important thing has already happened—you've opened a ticket and expressed your viewpoint. Trust me, that's what this project lacks the most. We're not tied to any specific strategy, so I see no issue in adapting to community feedback. What we really need is opinions.

I've learned from the mistakes made in the recent releases (two of which were yanked), and I'll strive to be more cautious in the future. However, I'd like to ask you and everyone reading this: Without your feedback, guys, we're not going anywhere. Thank you for continuing to trust us and for loving this project. That's essentially why we started all this. Keep giving us feedback. Keep talking to us. Don't hesitate to test in your own environments. Don't rush to update. Participate in the project's development.

Best regards,

[pataquets]

I'd like to add my +1 to @jonnyhsu's OP in exprssing my gratitude to @sergeyklay and @joke2k and acknowledgement in how useful this package is. Thank you very much for sharing such a useful package!
Also adding my +1 on OP's expressed views.

Since @sergeyklay mentions collaborative feedback is less than what he'd like to be, I'd like to point to Github's discussions feature in case it can be of any help (you can even convert issues needing further discussion in discussion threads). Just My 2c.

Maybe it even can be more prominently stated somewhere in the contributing docs, such as a call to opening a discussion previous to sending PRs, maybe (somewhere around here, for instance).

Also, since I'm a newbie user of the package, I can at least bring my "new user DX tester" perspective, and I can also definitely help improving docs with clarifications or examples, if needed. Actually, I'm browsing issues searching for some specific usage which I will definitely add to docs if I can't find it (I'll raise a separate issue later, if needed).