[bug#49834] Add dynaconf

[paul <goodoldpaul@autistici.org>]

Dear Sarah,

On 8/29/21 12:46 AM, Sarah Morgensen wrote:
> Did you receive my other email?  I found that in fact none of the flake8
> packages, as well as some others, are actually required.  I apologise if
> merging these bugs caused it to get lost!  I'll quote it below.
No I did not :( . Also I'm sorry about the confusion with the multiple 
bug reports, I forgot to send the patches directly to the ticket address.
> * gnu/packages/python-xyz.scm (python-colorama-0.4.1): New variable,
> (python-dotenv-0.13.0): New variable,
> (dynaconf): New variable.
>> Packages typically get one commit per package (so this would be three
>> commits).
I wasn't sure about this because right now those exact versions are only 
needed by dynaconf. Anyway I divided them in three commits.
>>>   * gnu/packages/patches/dynaconf-Unvendor-dependencies.patch: New file.
>>    ^ an extra space slipped in here.
>>
>>> [...]
>>> +    (arguments
>>> +     `(#:phases
>>> +       (modify-phases %standard-phases
>>> +         (replace 'check
>>> +           (lambda* (#:key tests? outputs #:allow-other-keys)
>>> +             (when tests?
>>> +               (setenv "PATH"
>>> +                       (string-append (assoc-ref outputs "out") "/bin:"
>>> +                                      (getenv "PATH")))
>>> +               ;; These tests depend on hvac and a
>>> +               ;; live Vault process.
>>> +               (delete-file "tests/test_vault.py")
>>> +               (invoke "make" "test_only"))
>>> +             #t)))))
>>                  ^ Nitpick: phases no longer have to end in #t, though it
>>                  doesn't hurt.
Thank you I didn't know it, fixed!
>>
>>> +    (propagated-inputs
>>> +     `(("python-click" ,python-click)
>>> +       ("python-dotenv" ,python-dotenv-0.13.0)
>>> +       ("python-ruamel.yaml" ,python-ruamel.yaml)
>>> +       ("python-toml" ,python-toml)))
>>> +    (native-inputs
>>> +     `(("make" ,gnu-make)
>>> +       ("python-codecov" ,python-codecov)
>>> +       ("python-configobj" ,python-configobj)
>>> +       ("python-colorama" ,python-colorama-0.4.1)
>>> +       ("python-django" ,python-django)
>>> +       ("python-flake8" ,python-flake8)
>>> +       ("python-flake8-debugger" ,python-flake8-debugger)
>>> +       ("python-flake8-print" ,python-flake8-print)
>>> +       ("python-flake8-todo" ,python-flake8-todo)
>>> +       ("python-flask" ,python-flask)
>>> +       ("python-future" ,python-future)
>>> +       ("python-pep8-naming" ,python-pep8-naming)
>>> +       ("python-pytest" ,python-pytest-6)
>>> +       ("python-pytest-cov" ,python-pytest-cov)
>>> +       ("python-pytest-forked" ,python-pytest-forked)
>>> +       ("python-pytest-mock" ,python-pytest-mock)
>>> +       ("python-pytest-xdist" ,python-pytest-xdist)
>>> +       ("python-radon" ,python-radon)))
>> With the test_only target, I think only a few of these are actually
>> required. Also, configobj should probably be a propagated input as
>> dynaconf uses it for ini files. I've attached a patch below.
>>
>> Notably, this seems to make python-flake8-debugger, python-flake8-todo,
>> python-pep8-naming and python-colorama-0.4.1 unneccessary (I think
>> because they are used for code linting, and the test_only target doesn't
>> do linting). WDYT?
>>
>> (Even if they aren't necessary for packaging dynaconf, you're still
>> welcome to send them as separate patches :)
I definitely agree, I'll send them as separate patches.
>>
>>> +    (home-page
>>> +     "https://github.com/rochacbruno/dynaconf")
>>         ^ Nitpick: this can go on one line
>>         
>>> +    (synopsis
>>> +     "The dynamic configurator for your Python Project")
>>         ^ Likewise
>>         
>>> +    (description
>>> +     "This package provides @code{dynaconf} the dynamic configurator for
>>> +your Python Project.")
>> Even as someone who has used python a lot before, this doesn't tell me
>> anything about what dynaconf actually does or why I might want to
>> install it. (Or, is it even an end-user package?) For examples, take a
>> look at pretty much any package which has more than two lines in its
>> description (like, say, python-seaborn). I know writing a good
>> description can be difficult, but they tend to stick around and read by
>> lots of people, so getting it right the first time is important!

I updated the description with the feature set provided on the main 
website, it should be a little more clear now .


I'm sending an updated patchset, thank you for your time :)


Giacomo