ANN: django-yamlconf v1.2.0 is available

[Michael Rohan]

Hi Folks,

Have release v1.2.0 for django-yamlconf, a module supporting Django settings via YAML files (searching up the directory hierarchy, e.g., in a K8s environment, adding a "final" set of settings via "/APPLICATION.yaml", see the documentation a https://django-yamlconf.readthedocs.io/en/latest/ for more detailed info.

The updates for the this release are:

- Tagged with ``v1.2.0``.
- Updates to support Django 3.0: Simply use "`six`" instead of the
  support "`django.utils.six`" package and use "`render`" instead of
  "`render_to_response`".
- `ycsysfiles` should generate executable files if the source template
  file is executable.
- Ensure the absolute path is used when searching for YAML control
  files.  This issue is seen when running Django apps under uWSGI
  control.
- Added the built-in attribute ``CPU_COUNT`` (primarily for use in uWSGI
  ini files) giving the number of available CPUs.

Take care,

Michael.

--

Michael Rohan
mro...@acm.org

[maninder singh Kumar]

Thanks for the info.

Maninder Kumar about.me/maninder.s.kumar

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAOCsNFhTf1Ar3paJ-3tJdVVZ1qO%2B-FWEzDOkiDtQwOBHJwiKRw%40mail.gmail.com.

[Gabriel - Iulian Dumbrava]

You are suggesting in the demos that the settings.py file should contain de development definition of variables and override them later on with loading the specific settings from yaml.

would contain the development oriented definitions, e.g., database definitions for user and password for a development database. The settings file would then end with a call the the load function. Additional definitions could be defined after the load function to update conditional definitions, e.g., if DEBUG is enabled.

This approach is not very security oriented because there is always the danger to forget to override a specific variable and hence make the app less secure. I would suggest to have the most secure, drastic values set by default in settings.py and then loosen them up in yaml files. But, it's only a suggestion.

Best regards,

Gabriel