maybe replace box with a simpler implementation.

Hello.

I stumbled upon your project and wondered: why would you rather have your dependencies "vendored" (that is, to keep a full copy of them inside this repo) instead of using a dependency management tool? If you have some time to answer this please let me know because I am curious about the reasoning to do so.

Hi @pavel-razgovorov

That decision was made because dynaconf started being packaged for many O.S including debian, RHEL, Arch.

To enable dynaconf to be a .rpm package for example it would require also the packaging of every dependency individually, so we decided to vendor it (the same way other projects does ex. https://github.com/pypa/pipenv/tree/master/pipenv/vendor for the same reason)

NOTE: The vendor_src is where the full copy is kept

The vendor contains a minified version to save disk space, the build process includes only the minified vendor

On some system such as Debian and GNU Guix, vendoring or bundling is against the packaging policy, so this won't help there. No matter how you look at it, bundled dependencies are almost always a bad idea and is akin to technical debt (what happens the day a bundled dependency is no longer supported by the current Python? You are either forced to do a large maintenance sprint to update them, or do development on the old bundled copies to bring them to compatibility).

@Apteryks once Python gets builtin TOML and YAML I am open to write a builtin implemention of Box and then remove all other dependencies.

@Apteryks vendoring is common on python projects, pip for example has some libraries vendored. As long as the licenses permits it is allowed.

Hi!, @rochacbruno! Would you be willing to reconsider this decision? I've responded inline to clarify my opinion. Thanks.

@rochacbruno:

@Apteryks vendoring is common on python projects,

This does not align with my experience in the Python ecosystem.

pip for example has some libraries vendored. As long as the licenses permits it is allowed.

This is a false equivalency. Pip has very specific and justified reasons for vendoring its dependencies. This is needed for bootstrap reasons and for safety reasons (other packages in the environment should not break the package installer). Even so, pip provides a way to unbundle the dependencies. Dynaconf does not have any of these problems, and the vendoring is not optional without patching out a bunch of hardcoded import paths, etc.

@Apteryks:

On some system such as Debian and GNU Guix, vendoring or bundling is against the packaging policy, so this won't help there.

This affects Fedora as well. Fedora discourages vendored dependencies. In cases where bundling is warranted (this is not one IMO), there's extra metadata that needs to be added and licenses that need to be accounted for. The vendored deps make it harder for us to package your software.

I came across this when submitting a PR to update Fedora's python3-dynaconf package and figured I'd engage with upstream on this.

No matter how you look at it, bundled dependencies are almost always a bad idea and is akin to technical debt (what happens the day a bundled dependency is no longer supported by the current Python? You are either forced to do a large maintenance sprint to update them, or do development on the old bundled copies to bring them to compatibility).

Yes, vendored dependencies can lead to technical debt. They also need to be babysat for security vulnerabilities, critical bugs, etc. They encourage bad development practice (e.g. just vendor an ancient dependency version and forget about it until a problem pops up and you need to scramble to fix a bunch of incompatabilities to get a security fix). This is less of a problem with normal Python dependency management. I almost always prefer to use packaged versions of dependencies instead of hidden vendored copies.

once Python gets builtin TOML and YAML I am open to write a builtin implemention of Box and then remove all other dependencies.

Python 3.11 and above have tomllib. I don't see the problem with external dependencies on tomli or pyyaml/ruamel.yaml.

@gotmax23 this is going to change on the release 4.0, not sure when, but 4.0 will be a metapackage pip install dynaconf will bring [dynaconf-core, dynaconf-toml, dynaconf-yaml, dynaconf-jinja, etc..`] so there will be some plugins and each plugin will bring its own deps.

each plugin will bring its own deps.

What do you mean by "bring its own deps?" Will those be vendored?

@gotmax23 for the plugins under the dynaconf/ org it will no more vendor anything, for external plugins it will depend on plugins.